Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Windows Azure Security Features And Functionality
Ähnlich wie Windows Azure Security Features And Functionality (20)
Windows Azure Security Features And Functionality
- 1. Windows Azure Security Features and Functionality Vivek Bhatnagar WW Lead Technical Sales Windows Azure Microsoft Corporation vivekbh@live.com
- 3. Windows Azure Combines Three Components Compute – Think Stateless CPU in the Cloud (Rented by the CPU - hour) Storage – Like a file system, but structured differently to support scalability and parallelism (Rented by the Gigabyte - Month) SQL Azure – Another form of storage, accessed with SQL queries rather than file-like operations Can be used separately, but more commonly a Compute tenant is layered atop Storage, SQL Azure, or both There will likely be more components in the future
- 4. 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
- 5. Threats We Worry About Physical Attacks On Servers Central Admin Users Customer Admin Windows Azure Customer Tenant External Web Site
- 6. 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 Physical Attacks On Servers Users Customer Admin Windows Azure Customer Tenant
- 7. 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 discovered Central Admin Windows Azure Customer Tenant
- 8. Using Windows Azure as a Platform for Attacking Others We will receive complaints of misbehavior by Windows Azure tenants We proactively monitor outbound access to detect common cases (port scans, spam) If a good customer’s tenant has been compromised (botted), we work with the customer to resolve the problem If a customer intentionally attacks others, we ban them Windows Azure Customer Tenant External Web Site
- 9. Threats Customer Still Must Worry About Users Customer Admin Windows Azure Customer Tenant
- 10. 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 We can look for symptoms in some cases, but it is ultimately the customer’s responsibility Users Windows Azure Customer Tenant
- 11. 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 Customer Admin Windows Azure Customer Tenant
- 12. Windows Azure Security Layers Network ACLs: dedicated VLANS for tenant nodes 12
- 13. 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, we create customer owned VMs, isolated by a hypervisor
- 14. 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
- 15. Hypervisor & VM Sandbox All Guest access to network and disk is mediated by Root VM (via the Hypervisor) Guest VM Guest VM Guest VM Guest VM Guest VM Guest VM Guest VM Root VM Hypervisor Network/Disk
- 16. Managing it all through the Fabric Controllers
- 17. 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
- 18. 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
- 19. 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
- 21. Shared access signatures supports some forms of limited delegationA 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
- 22. 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.
- 23. Windows Azure Storage Security Data from many customers is mixed in a single pool 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
- 24. 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 Data from many customers is pooled in a single SQL instance, but they are treated as separate and access controlled independently
- 25. Defenses Inherited by Windows Azure Tenants Spoofing Tampering & Disclosure Elevation of Privilege Denial of Service Load-balanced Infrastructure Network bandwidth throttling CiscoGuard enabled on Storage nodes Configurable scale-out 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 Port Scanning/ Service Enumeration Service Definition file, Windows Firewall, VM switch packet filtering
- 26. © 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
Hinweis der Redaktion
- Services are isolated from other servicesCan only access resources declared in the service model .Local node resources – temp storageNetwork end-pointsIsolation using multiple mechanismsMuch of the traditional infrastructure security moves to the platform and application layersNetwork Access Control Lists and Firewalls become host packet filters and virtual firewallsMultiple, privileged accounts become pre-defined agent accounts controlled by the systemPlatform and network level encryption will still play a role, but the application developer becomes more responsible for defining how encryption is used end-to-endServices are isolated from other servicesCan only access resources declared in the service model .Local node resources – temp storageNetwork end-pointsIsolation using multiple mechanismsAutomatic application of windows security patchesRolling operating system image upgrades
- Port Scanning/ Service EnumerationThe only ports open and addressable (internally or externally) on a Windows Azure VM are those explicitly defined in the Service Definition file. Windows Firewall is enabled on each VM in addition to enhanced VM switch packet filtering, which blocks unauthorized traffic Denial of Service Windows Azure’s load balancing will partially mitigate Denial of Service attacks from the Internet and internal networks. This mitigation is done in conjunction with the developer defining an appropriate Service Definition VM instance count scale-out. On the Internet, Windows Azure VMs are only accessible through public Virtual IP Addresses (VIPs). VIP traffic is routed through Windows Azure’s load-balancing infrastructure. Windows Azure monitors and detects internally initiated Denial of Service attacks and removes offending VMs/accounts from the network. As a further protection, the root host OS that controls guest VMs in the cloud is not directly addressable internally by other tenants on the Windows Azure network and the root host OS is not externally addressable.Windows Azure is also reviewing additional Distributed Denial of Service (DDoS) solutions available from Microsoft Global Foundation Services to help further protect against Denial of Service attacks.SpoofingVLANs are used to partition the internal network and segment it in a way that prevents compromised nodes from impersonating trusted systems such as the Fabric Controller. At the Hypervisor VM Switch, additional filters are in place to block broadcast and multicast traffic, with the exception of what is needed to maintain DHCP leases. Furthermore, the channel used by the Root OS to communicate with the Fabric Controller is encrypted and mutually authenticated over an HTTPS connection, and it provides a secure transfer path for configuration and certificate information that cannot be intercepted.Eavesdropping / Packet SniffingThe Hypervisor’s Virtual Switch prevents sniffer-based attacks against other VMs on the same physical host. Top-of-rack switches will be used to restrict which IP and MAC addresses can be used by the VMs and therefore mitigate spoofing attacks on internal networks. To sniff the wire inside the Windows Azure cloud environment, an attacker would first need to compromise a VM tenant in a way that elevated the attacker to an administrator on the VM, then use a vulnerability in the hypervisor to break into the physical machine root OS and obtain system account privileges. At that point the attacker would only be able to see traffic inbound to the compromised host destined for the dynamic IP addresses of the VM guests controlled by the hypervisor. Multi-tenant hosting and side-channel attacksInformation disclosure attacks (such as sniffing) are less severe than other forms of attack inside the Windows Azure datacenter because virtual machines are inherently untrusted by the Root OS Hypervisor. Microsoft has done a great deal of analysis to determine susceptibility to side-channel attacks. Timing attacks are the most difficult to mitigate. With timing attacks, an application carefully measures how long it takes some operations to complete and infers what is happening on another processor. By detecting cache misses, an attacker can figure out which cache lines are being accessed in code. With certain crypto implementations involving lookups from large tables, knowing the pattern of memory accesses - even at the granularity of cache lines - can reveal the key being used for encryption. While seemingly far-fetched, such attacks have been demonstrated under controlled conditions. There are a number of reasons why side-channel attacks are unlikely to succeed in Windows Azure: An attack works best in the context of hyper-threading, where the two threads share all of their caches. Many current CPUs implement fully independent cores, each with a substantial private cache. The CPU chips that Windows Azure runs on today have four cores per chip and share caches only in the third tier.Windows Azure runs on nodes containing pairs of quad-core CPUs, so there are three other CPUs sharing the cache, and seven CPUs sharing the memory bus. This level of sharing leads to a great deal of noise in any signal from one CPU to another because actions of multiple CPUs tend to obfuscate the signal.Windows Azure generally dedicates CPUs to particular VMs. Any system that takes advantage of the fact that few servers keep their CPUs busy all the time, and implements more logical CPUs than physical CPUs, might open the possibility of context switches exposing cache access patterns. Windows Azure operates differently. VMs can migrate from one CPU to another, but are unlikely to do so frequently enough to offer an attacker any information.