3. Introduction
Objective was to deliver service-oriented architecture for
online system to store and to search through a highly
sensitive data using budget effective approach.
Captivated by the benefits of cloud computing decided to
take a plunge into the new world.
Objectives: high-security of the data at all time, ability to
move around cloud providers and the world, minimal
downtime due to outage, disaster or even court shutdown
order.
4. Challenges and Decisions
Technology selection: Microsoft stack primarily due to
higher productivity using well-supported software/tools and
amount of information available from community.
Cloud Provider Selection: Azure, Amazon, Rackspace,
and etc.- decided to try few of the above, with objective to
be able to move between cloud providers and shared
hosting providers with no source code changes.
Multi-Level Security: username/password for
authentication, end-user identity token through all layers of
application, data-in-transit encryption, data at rest
encryption, backup encryption.
5. Software Architecture
Front-End: Html 5 and JavaScript over Https with
emphasis on streamlined and lean user-interfaces with fast
response whether on Desktop, on Internet Tables, or on
SmartPhone.
Web Server - IIS 7.5 the latest available as of time of
development. Coding - C# MVC3 with Razor syntax as the
latest flavour for web application development.
Service Layer: WCF over Https on IIS7.5. Entity
Framework with C# POCO objects for WCF serialization in
N-tier environment. Connection to the Db TCP/IP over Ssl
Back-End: Sql Server 2008 R2 Enterprise Edition with
Transparent Data Encryption for data protection at rest.
6. Security Architecture
Front-End: User authentication at first using Verisign OpenId,
and later switched to Username/Password with password
hashed and stored in Sql Server - users did not like the
intermediate step during sign-in. All traffic is over Https.
Service Layer: End-user time-sensitive token issued upon
authentication and is being used to validate user identity and
permission on each service operation request. All traffic is over
Https.
Back-End: Application account with permission to execute few
stored procedures to validate user credentials and user-token.
Secondary application account with full access using 15 min
time-to-leave password and encrypted for each user-token. All
connections encrypted using Ssl. Data at-reset protected by Sql
Server TDE, ISP administrative account(s) disabled.
7. Hosting Architecture
Front-End: Windows Azure Web Role with two instances for load-
balancing and fault tolerance purposes. Since there is no credentials
stored here - the web application can be deployed anywhere including
shared hosting.
Service Layer: Amazon EC2 Windows Server 2008 R2 two instances
with load-balancing enabled. Encrypted credentials for limited access
database account - not end of the world even if hacked.
Back-End: few were tried: Virtual on Amazon EC2 Windows Server R2
(robust but not cheap), Virtual on Go-Daddy VPS (cheap but slow), and
iHost physical server for best combination of cost and performance.
Hosting company must have no login credentials to the box.
Backup: few tried and rejected due to lousy security practices -
confirmation email sent contained password. One that supported in-
transit and at-rest data encryption was selected, additionally Sql
backup file was also encrypted by TDE itself - no unencrypted data
anywhere.
