ms cloud day - understanding and implementation on windows azure platform security
DESCRIPTION
TRANSCRIPT
Tan Choon Ngee Director, aZaaS Pte Ltd
Microsoft Cloud Day
Understanding and implementation Windows Azure platform security
Choon Ngee has more than 10 years of IT Sales, Marketing and Consulting experience with leading organizations like JP
Morgan and Crimson Logic. He has developed several businesses focussed purely on Microsoft Technologies
during this period.
This session focuses on the security challenges and recommended approaches to design and develop more
secure applications for Microsoft’s Windows Azure platform.
Understanding and implementation Windows Azure platform security
• Microsoft Corporation• Authors Andrew Marshall (Senior Security Program Manager,
Security Engineering) Michael Howard (Principal Security Program Manager, Security Engineering) Grant Bugher (Lead Security Program Manager, OSSC) Brian Harden (Security Architect, OSSC)
• Contributors Charlie Kaufman (Principal Architect) Martin Rues (Director, OSSC) Vittorio Bertocci (Senior Technical Evangelist, Developer and Platform Evangelism
Responsibility for Threat Mitigation
• There are many threats to a traditional server• There are some additional threats in the case
of cloud computing• Some threats are handled by Windows Azure;
others remain the responsibility of the customer
Windows Azure Security Certifications
• ISO/IEC 27001:2005 certification• SAS 70 Type 1 and II attestations• PCI Data Security Standard compliance• Sarbanes–Oxley Act compliance• Health Insurance Portability and
Accountability Act compliance
External Verification
• Microsoft contracted two top-tier penetration testing firms
• Conduct security assessments on different elements of the Windows Azure architecture
• Examined hardened virtualization boundaries and • Probed for side-channel or I/O thrashing attacks• Six professional penetration testers working over the
course of seven weeks were unable to mount a successful attack against this design.
Threats Handled by Azure
Windows Azure
Customer Tenant
Customer Admin Users
External Web Site
Physical AttacksOn ServersCentral Admin
Attacks against Windows Azure
• A successful attack on the infrastructure could compromise all of our customers
• Windows Azure must secure its facilities against unauthorized access
• Windows Azure must secure its interfaces against attacks over the network– Customer tenants breaking out of their VMs– Attackers successfully impersonating customer administrators or Windows
Azure administrators– Customer administrators affecting
other than their own tenants
Windows Azure
Customer Tenant
Customer Admin Users
Physical AttacksOn Servers
Abuse of Privilege by Windows Azure Administrators
• Windows Azure administrators could make unauthorized access to customer data– Procedures involving customer consent when such
access is necessary– Separation of Duty to prevent abuse by a single
rogue administrator– Auditing to assure that unauthorized access will
be discoveredWindows Azure
Customer Tenant
Central Admin
Using Windows Azure as a Platform for Attacking Others
• MS will receive complaints of misbehavior by Windows Azure tenants
• MS proactively monitor outbound access to detect common cases (port scans, spam)
• If a good customer’s tenant has been compromised (botted), MS work with the customer to resolve the problem
• If a customer intentionally attacks others, MS ban them
Windows Azure
Customer Tenant
External Web Site
Defenses Inherited by Windows Azure Tenants
Spoofing Tampering & Disclosure
Port Scanning/ Service
Enumeration
Elevation of Privilege
Load-balanced Infrastructure
Network bandwidth throttling
CiscoGuard enabled on Storage nodes
Configurable scale-out
Denial of Service
Service Definition file, Windows Firewall, VM switch packet filtering
VM switch hardening
Certificate Services
Shared-Access Signatures
HTTPS
Sidechannel protections
VLANs
Top of Rack Switches
Custom packet filtering
Partial Trust Runtime
Hypervisor custom sandboxing
Virtual Service Accounts
Windows Azure Security Layers
18
Managed Code Access Security: partial trust
Windows Account: running with least privileges
Windows FW (VM): rules based on service model
Virtual Machine: fixed CPU, memory, disk resources
Root Partition Packet Filter: defense in depth against VM “jailbreaking”
Network ACLs: dedicated VLANS for tenant nodes
How does it work?
• For Windows Azure Storage and SQL Azure, like any other shared service– Storage or SQL account owned by some customer
who sets access policy– Access policy is enforced by the code that parses
and satisfies requests• For Windows Azure Compute, MS create
customer owned VMs, isolated by a hypervisor
Underlying Hardware
• Rack mounted servers• Each rack has a collection of identical nodes• Each node (currently) has 2 CPU chips with 4
cores each– 16 Gig of memory– Disks for local storage– Network Interface to a Top of Rack Switch
Hypervisor & VM Sandbox
All Guest access to network and disk is mediated by Root VM (via the Hypervisor)
Hypervisor
Network/Disk
Root VM
Guest VM
Guest VM
Guest VM
Guest VM
Guest VM
Guest VM
Guest VM
Managing it all through the Fabric Controllers
What does the world look like to a Guest VM?
• 1, 2, 4, or 8 CPUs; up to 14 GB or memory• Three disk drives:– C:\ (for temps; initially populated with config file)– D:\ (for OS code; initially as supplied by Windows
Azure)– E:\ (for application code; initially as supplied by
customer admin)• Network connectivity to Internet via NAT and to
other VMs of same tenant• Guest agent accepts incoming HTTP/RPC
connections from Root OS
Handling Attacks by a Tenant
• Not dependent on the security of Windows• Instead, dependent on the security of the
Hypervisor and the exposed network and disk drivers
• C:\, D:\, and E:\ are not really disks. They are VHD files in the root OS’s file system.
• Attack surface is minimized by accepting few commands and supporting only a few hardware devices
Windows Azure Storage
• Runs on separate hardware with no network connectivity to compute except (logically) through Internet
• Requests run over HTTP and optionally over SSL with server authentication
• Storage is organized into storage accounts• A single customer may have many storage accounts• A single secret key controls all access to a storage
account
Access Control
• Some accommodation to more fine-grained access controls:– Some data can be marked as world-readable– Shared access signatures supports some forms of limited
delegation
• A customer wanting fine-grained access controls can implement a front end compute tenant that has full access to the storage account but mediates access to data items
Windows Azure Storage Scalability
• To reduce the need for locks when dealing with a conventional file system, Windows Azure storage implements the primitives: blobs, tables, and queues.
• For backwards compatibility, it also implements an virtual drive with disk semantics for applications that have not been converted.
• The customer is responsible for coordinating the assignment of virtual drives to VMs. A virtual drive can only be open for write from one VM at a time.
Windows Azure Storage Security
• Access to data in a specific account is only granted to entities having the secret key for that account
• Storage keys are randomly generated when the storage account is created (or later at the request of the customer)
• A storage account may have two active keys at any given time to support key rollover
• Storage keys are used to HMAC sign each access request
SQL Azure
• As with storage, runs on separate hardware with no connectivity to compute except (logically) over the Internet
• Developer portal can create databases and set an administrator password
• SQL administrator can create additional user accounts, each authenticated with a password
Threats Customer Still Must Worry About
Windows Azure
Customer Tenant
Customer Admin Users
Abuse of Privilege by a Customer Administrator
• Customer administrators are authorized to update the code and access the data belonging to any customer tenant
• Customer administrators are authenticated with cryptographic keys that the customer must protect
• Customers should implement deployment practices as carefully as they would for applications in their own data centers
Windows Azure
Customer Tenant
Customer Admin
Attacks on a Customer’s Tenant
• A tenant is much like a physical server. If there are bugs in its code, it can be compromised over the network
• MS can look for symptoms in some cases, but it is ultimately the customer’s responsibility
Windows Azure
Customer Tenant
Users
Securing the Front Door
• Identity Management and Access Control– Windows Identity Foundation – Active Directory Federation Services 2.0 – Windows Azure AppFabric Access Control Service
Authenticating Users
AppFabricACS
Service Identities
ADFS2 . WS-Trust
ADFS2 . WS-Federation
WS-Trust
OAuth WRAP/2.0
WS-Federation
SAMLSWT
SAML
SWT
Your ApplicationACSIdentityProviders
Brow
ser-
base
dRi
chCl
ient
Serv
er 2
Ser
ver
Gatekeeper Design Pattern
Multi Key Design Pattern
Example of Architecture
Queue
Input Queue (Work Items)
Web Role
Web Role
Web Role
Worker Role
Worker Role
Worker Role
Worker Role
Storage
Namespace Configuration Issues
• Avoid using *servicename*.cloudapp.net domain name - use a custom domain name instead. – cloudapp.net namespace is inherently less trusted than the
domain namespace of a single enterprise – Don’t create code that requires users to place cloudapp.net in
the trusted sites list in their web browser. • Never scope cookies or document.domain to cloudapp.net.
– Instead, scope to the service subdomain (such as contoso.cloudapp.net, for example or, better, www.contoso.com).
Data Security
• Generate Shared Access Signatures with the most restrictive set of ACLs possible that still grant the access required by the trusted party.
• Use the shortest lifetime possible. • Use HTTPS in the request URL so the token cannot be
snooped on the wire. • Remember that these tokens are only used for
temporary access to non-public blob storage – as with passwords, it’s a bad idea to use the same ones over and over
Handling Secret Information
• Encrypt data offsite then upload encrypted payload to blob storage
• Should not upload the key or any keying material to Windows Azure Storage
• Should not store private keys associated with SSL/TLS certificates in Windows Azure Storage. – Instead, upload them through the Developer Portal and access
them via thumbprint references in the Service Configuration. – Windows Azure will securely provision them into the
certificate stores of the service’s web roles upon boot
Auditing and Logging
• Events are not written to application, security, or audit event logs
• Logged to Windows Azure Storage through the Monitoring and Diagnostics Agent via trace listeners in web application code.
• Then stored long-term in Windows Azure Storage via scheduled transfers performed by the Monitoring Agent.
• Not encrypted - Do not write sensitive information to any events stored in Windows Azure Table Storage
• Choose HTTP or HTTPS to retrieve logs
Request Throttling / Input Sanitization
• Developers must do application-level throttling of incoming requests for any kind of complex, time-intensive operation.
• Fuzz test any new parsers deployed as part of a web service. – Fuzz test it to ensure the code can correctly accommodate
malformed input. – Microsoft currently applies to “boxed-product” software
fuzzing requirement : 100,000 iterations of each new format or protocol without crashing, or runs non-stop for 24 hours
Other Security Considerations
• Secure design– Attack surface reduction – Defense in depth – Principle of least privilege – Threat modeling
• Secure coding– Cross-site scripting – SQL injection – Managed code security (transparency, code access security,
assembly strong naming, etc.)
Today’s Promotion• FREE* for first 5 customers only! Email promotion code
“AZURE6M” with your contact details to [email protected] to register.
• Special package worth S$3800• 6 months of Windows Azure Platform DAE• 6 months of aZaaS Cloud Application Engine subscription• 2 man-days of services to create your cloud application• Offer is only valid till 30 April 2011*Credit card required for sign-up. Any monthly usage in excess of the stated amounts will be charged at the standard rates. After 6 months, all usage will then be charged at the standard rates. Testimonial regarding services from Microsoft and aZaaS will be required.
Microsoft Cloud Day