top of page

Molnet är säkrare än ert eget datacenter - del 3 av 4

Skribentens bild: Martin EdeliusMartin Edelius

"Molnet är osäkert."

Ett vanligt argument för att inte använda molnet är att det är osäkert. Oftast går man inte in på detaljer eftersom man inte känner till dem, och ibland rättfärdigas argumentet med att "juristerna" eller "lagen" inte tillåter det. I de absolut flesta fall håller argumentet inte, och när det används som en generell ursäkt för att inte använda moln baseras det på felaktiga grunder.

I del ett av den här artikelserien i fyra delar gav jag min syn på varför det inte är ett problem att alla relevanta molnleverantörer är baserade i USA. I del två beskrev jag vad en molnleverantör gör för att skydda er information och varför jag anser att detta innebär att molnet är säkrare än ert eget datacenter.

I del tre, dit vi nu kommit, går jag igenom de tekniska förmågor molnleverantörerna använder för att skydda er information och i del fyra kommer jag beskriva vilka möjligheter ni själva har för att säkra er information.

Som vanligt är ni mer än välkomna att komma med tankar, frågor, funderingar och motargument i kommentarerna.

Tekniskt, men begripligt

Precis som tidigare kommer jag fokusera på Microsoft då det är deras molntjänster jag är bekväm med. Med detta sagt använder exempelvis AWS och GCP sig av liknande teknologier.

Det finns en uppsjö av dokumentation som i detalj beskriver hur Microsoft skyddar er information. Min avsikt är inte att återge alla dessa detaljer, eller att djupdyka i specifika lösningar, utan att sammanfatta tekniken så att de av er som vill kan läsa vidare på egen hand.

Med detta sagt är det dock oundvikligt att jag kommer bli mer teknisk än i de tidigare delarna. Jag uppmuntrar trots detta de av er som i normala fall inte behöver förstå tekniken att läsa igenom artikeln då jag kommer göra mitt bästa för att göra texten begripligt för så många som möjligt.

Vad gör Microsoft?

På grund av hur enormt stort ett "hyperscale cloud" är kan (och måste) Microsoft designa sina tjänster på ett sätt som är mycket mer effektivt och säkert än vad normala organisationer mäktar med. Tekniken är i sig sällan unik, det är hur och när den implementeras som skiljer sig mellan molnet och ert eget datacenter.

Även om Microsoft har stora mängder information tillgängligt publikt finns det bara så mycket man kan hitta. Jag vill dock endast använda källor som är publikt tillgängliga på Internet, dels så att ni kan läsa vidare och dels så att ni kan kontrollera mina påståenden.

Hårdvara

Microsoft är aktiva inom Open Compute Project (OCP), som bland annat innehåller den serverhårdvara Microsoft kör i delar av sina Azure datacenter, och har i detta forum introducerat Project Cerberus [1]:

Project Cerberus is a NIST 800-193 compliant hardware root of trust specifically designed to provide robust security for all platform firmware. It provides a hardware root of trust for firmware on the motherboard (UEFI BIOS, BMC, Options ROMs) as well as on peripheral I/O devices by enforcing strict access control and integrity verification from pre-boot and continuing to runtime.

NIST är "The National Institute of Standards and Technologies" och är en del av USAs regering [2].

En mer detaljerad beskrivning av Project Cerberus finns i OCPs GitHub repository för projektet [3]. Microsofts presentation av Project Cerberus på OCP Summit 2018 är också läsvärd [4].

Så vitt jag vet finns inte hårdvaran som beskrivs i Project Cerberus implementerad i traditionella servrar, däremot går det att använda TPM-chipet i moderna servrar för att bygga en säker miljö med exempelvis "guarded fabric" [5].

Kryptering

I Azure är det väldigt mycket upp till dig som kund att välja hur du vill skydda din information men i Office 365 har du som kund inte samma möjligheter att bestämma över hur din information skyddas så av den anledningen kommer jag också beskriva hur informationen i Office 365 krypteras [6].

Office 365 servers use BitLocker to encrypt the disk drives containing customer data at rest at the volume-level.

BitLocker is deployed with Advanced Encryption Standard (AES) 256-bit encryption on disks containing customer data in Exchange Online, SharePoint Online, and Skype for Business. Disk sectors are encrypted with a Full Volume Encryption Key (FVEK), which is encrypted with the Volume Master Key (VMK), which in turn is bound to the Trusted Platform Module (TPM) in the server.

De hemligheter som skyddar BitLocker-krypteringen existerar på tre nivåer; per server (AES 265-bitars extern nyckel), per disk (48 siffrors numeriskt lösenord), och per miljö - exempelvis Exchange Online multi-tenant - (X.509 certifikat utfärdat av Microsofts CA). Dessa hemligheter lagras dessutom på olika ställen och ingen enskild person har access till dem.

Den här tekniken är i sig inte unik för Microsoft och kan implementeras i ert datacenter om ni önskar, även om den exakta implementationen förmodligen skiljer.

Förutom att skydda informationen när den lagras på disk skyddar Microsoft även informationen i Office 365 när den skickas över nätverket [7].

Inter-datacenter communications between Office 365 servers takes place over TLS or IPsec, and all customer-facing servers negotiate a secure session using TLS with client machines (e.g., Exchange Online uses TLS 1.2 with 256-bit cipher strength is used (FIPS 140-2 Level 2-validated). (See Technical reference details about encryption in Office 365 for a list of TLS cipher suites supported by Office 365.) This applies to the protocols that are used by clients such as Outlook, Skype for Business, and Outlook on the web (e.g., HTTP, POP3, etc.).

Inte heller den här tekniken är unik för Microsoft.

Nätverkstrafiken i Azure är mer komplicerad att beskriva i detalj men kortfattat måste all trafik mellan VM krypteras av er som kund, i övrigt krypteras trafiken av Microsoft [8].

Azure protects data in transit to or from outside components and data in transit internally, such as between two virtual networks. Azure uses the industry-standard Transport Layer Security (TLS) 1.2 or later protocol with 2,048-bit RSA/SHA256 encryption keys[…]

Den här typen av kryptering finns tillgänglig för er att implementera i ert datacenter.

Isolering

Azure Active Directory

För att isolera kunder och deras information från varandra använder Microsoft ett flertal teknologier [9], men den främsta är Azure Active Directory (AAD) [10].

Azure Active Directory was designed to host multiple tenants in a highly secure way through logical data isolation. Access to Azure Active Directory is gated by an authorization layer. Azure Active Directory isolates customers using tenant containers as security boundaries to safeguard a customer's content so that the content cannot be accessed or compromised by co-tenants. Three checks are performed by Azure Active Directory's authorization layer:

  • Is the principal enabled for access to Azure Active Directory tenant?

  • Is the principal enabled for access to data in this tenant?

  • Is the principal's role in this tenant authorized for the type of data access requested?

No application, user, server, or service can access Azure Active Directory without the proper authentication and token or certificate. Requests are rejected if they are not accompanied by proper credentials.

Förutom att isolera kunder i Office 365 används AAD även för att isolera kunder i Azure [11].

With the identity platform provided by Microsoft Azure, a tenant is simply a dedicated instance of Azure Active Directory (Azure AD) that your organization receives and owns when it signs up for a Microsoft cloud service.

Tenant level isolation in Microsoft Azure is achieved using Azure Active Directory and role-based controls offered by it. Each Azure subscription is associated with one Azure Active Directory (AD) directory.

Det finns en tydlig och rigorös separation av kunder ("tenants") i AAD [11].

Azure Active Directory hosts each tenant in its own protected container, with policies and permissions to and within the container solely owned and managed by the tenant.

The concept of tenant containers is deeply ingrained in the directory service at all layers, from portals all the way to persistent storage.

Even when metadata from multiple Azure Active Directory tenants is stored on the same physical disk, there is no relationship between the containers other than what is defined by the directory service, which in turn is dictated by the tenant administrator.

Som jag nämnt i tidigare delar i serien kommer ingen personal från Microsoft åt kundinformation annat än med kundens uttryckliga godkännande, eller i samband med brottsutredning, och detta gäller även för AAD.

AAD är inte tillgängligt att implementera i ert datacenter men det finns många andra sätt att uppnå liknande typ av säkerhet, exempelvis via Active Directory.

Virtuella maskiner i Azure

För att säkerställa att de virtuella maskiner (VM) som körs i Azure inte har möjlighet att komma åt information i andra VM tillämpar Microsoft "compute isolation." De uppnår denna isolering med hjälp av olika tekniker [12, kräver gratis konto].

  1. Hyper-V & Root OS Isolation Between Root VM & Guest VMs

  2. Advanced VM placement algorithm & protection from side channel attacks

  3. The Azure Fabric Controller

Den första tekniken är traditionell virtualisering av datorkraft. Microsoft använder Hyper-V som plattform ("hypervisor") för de VM ("guest OS") som körs i Azure. En specifik VM, kallad "Root VM," används för att köra och hantera Hyper-V. Denna körs i vad som kallas "Ring 0 (noll)" [12, kräver gratis konto].

Ring 0 is the most privileged and 3 is the least. The guest OS runs in a lesser-privileged Ring 1, and applications run in the least privileged Ring 3. This virtualization of physical resources leads to a clear separation between guest OS and hypervisor, resulting in additional security separation between the two.

Hyper-V ingår i Windows Server sedan 2008 och kan användas av vilken organisation som helst om de så önskar. Ett liknande skydd uppnås även med hjälp av andra hypervisors, exempelvis ESXi eller RHV/KVM.

Genom att utnyttja avancerade algoritmer för placering av VM på fysiska servrar i Azure, samt genom att implementera skydd mot attacker från angränsande VM minimerar Microsoft risken att en VM skall kunna attackera en annan [12, kräver gratis konto].

Any cross-VM attack involves two steps: placing an adversary-controlled VM on the same host as one of the victim VMs, and then breaching the isolation boundary to either steal sensitive victim information or affect its performance for greed or vandalism. Microsoft Azure provides protection atboth steps by using an advanced VM placement algorithm and protection from all known side channel attacks including noisy neighbor VMs.

Dokumentationen nämner inte exakt hur den här placeringen går till så jag kan inte säga att precis den här tekniken finns tillgänglig generellt. Det finns dock algoritmer för placering av VM samt skydd för s.k. "noisy neighbors" i Hyper-V.

"The Azure Fabric Controller" är en funktion som har det yttersta ansvaret för hur resurser tilldelas och hur kommunikationen mellan gäster (VM) och underliggande hårdvara sker [12, kräver gratis konto].

The Azure Fabric Controller is responsible for allocating infrastructure resources to tenant workloads, and it manages unidirectional communications from the host to virtual machines. The VM placing algorithm of the Azure fabric controller is highly sophisticated and nearly impossible to predict as physical host level.

Detaljerna runt hur detta fungerar är för tekniska för att gå in på i detalj i den här artikeln men det är värt att nämna hur kommunikationen mellan "Fabric Controllern" (FC) och de agenter som körs för att hantera hårdvara och gäster (VM) fungerar [12, kräver gratis konto].

Communication from a Fabric Controller to an agent is unidirectional. The agent implements an SSL protected service that only responds to requests from the controller. It cannot initiate connections to the controller or other privileged internal nodes. The FC treats all responses as if they were untrusted.

Förutom detta säkerställer Microsoft att de nycklar och lösenord som FC använder för att identifiera sig med när den kommunicerar med hårdvaran är skyddade så att FC inte kan komprometteras för att på så vis komma åt information i VM [13].

Microsoft uses encryption based on the FC’s master identity public key. This occurs at FC setup and FC reconfiguration times, to transfer the credentials used to access networking hardware devices. When the FC needs the credentials, the FC retrieves and decrypts them.

Jag har inte hittat någon information som indikerar att "The Azure Fabric Controller" finns tillgänglig utanför Azure, ens i Azure Stack.

Lagring i Azure

Lagring i Azure separeras fysiskt från hårdvaran som kör VM vilket innebär att det endast finns en logisk koppling de två emellan [11].

Nätverk i Azure

Även för nätverk använder Microsoft sig av isolering. I botten av deras nätverksstruktur finns tre stycken VLAN (icke att förväxlas med de VNet ni som kund kan skapa i Azure), där trafik inte tillåts från det nätverk som används för kunders VM ("main VLAN") till de nätverk som används för att hantera miljön ("FC VLAN" och "device VLAN") [14].

Communication is permitted from the FC VLAN to the main VLAN, but cannot be initiated from the main VLAN to the FC VLAN. Communication is also blocked from the main VLAN to the device VLAN. This assures that even if a node running customer code is compromised, it cannot attack nodes on either the FC or device VLANs.

Den här typen av nätverksdesign kan implementeras i ett lokalt datacenter.

I Azure körs kunders VM på egna virtuella nätverk, kallade VNet. Dessa är som standard separerade från alla övriga VNet, utan att ni som kund behöver göra något [15].

Virtual machines (VMs) in one virtual network cannot communicate directly to VMs in a different virtual network […]

Detta sker med hjälp av så kallad Software Defined Networking (SDN) som möjliggörs av Microsofts "Virtual Filtering Platform" [16].

The Virtual Filtering Platform (VFP) is a cloud-scale programmable virtual switch providing scalable SDN policy to one of the world’s largest clouds, Microsoft Azure. It was designed from the ground up to handle the programmability needs of Azure’s many SDN applications, the scalability needs of deployments of millions of servers, and to deliver the fastest virtual networks in the public cloud to Azure’s VMs through hardware offloads.

Motsvarande SDN som används i Azure finns tillgängligt för implementation i ert lokala datacenter [17].

Avslutningsvis

I nästa del går jag igenom de tekniska förmågor ni själva kan använda i molnet för att bestämma hur säker er information är (eller inte är). Till dess, tveka inte att kontakta mig, antingen via e-mail, telefon eller formuläret här på hemsidan, om ni är intresserade av att diskutera ämnet vidare med mig.

Tack för din tid!

Källor

  1. https://azure.microsoft.com/en-us/blog/microsofts-project-olympus-delivers-cloud-hardware-innovation-at-scale/

  2. https://www.nist.gov/about-nist

  3. https://github.com/opencomputeproject/Project_Olympus/tree/master/Project_Cerberus

  4. https://f990335bdbb4aebc3131-b23f11c2c6da826ceb51b46551bfafdc.ssl.cf2.rackcdn.com/images/fbbdd5feceb6e6328373417e1ab7c06a13a2ef2c.pdf

  5. https://docs.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms

  6. https://docs.microsoft.com/en-us/microsoft-365/compliance/office-365-bitlocker-and-distributed-key-manager-for-encryption?view=o365-worldwide

  7. https://docs.microsoft.com/en-us/microsoft-365/compliance/office-365-encryption-for-data-in-transit?view=o365-worldwide

  8. https://docs.microsoft.com/en-us/azure/security/fundamentals/protection-customer-data#data-protection

  9. https://docs.microsoft.com/en-us/office365/Enterprise/office-365-tenant-isolation-overview

  10. https://docs.microsoft.com/en-us/office365/Enterprise/office-365-isolation-in-azure-active-directory

  11. https://docs.microsoft.com/en-us/azure/security/fundamentals/isolation-choices

  12. https://servicetrust.microsoft.com/ViewPage/TrustDocuments?command=Download&downloadType=Document&downloadId=e2d75893-ef18-4c24-920b-7000ea9e1056&docTab=6d000410-c9e9-11e7-9a91-892aae8839ad_FAQ_and_White_Papers

  13. https://docs.microsoft.com/en-us/azure/security/fundamentals/infrastructure-components#azure-hardware-device-authentication

  14. https://docs.microsoft.com/en-us/azure/security/fundamentals/isolation-choices#vlan-isolation

  15. https://docs.microsoft.com/en-us/azure/security/fundamentals/isolation-choices#networking-isolation

  16. https://www.microsoft.com/en-us/research/wp-content/uploads/2017/09/login_fall17_02_firestone.pdf

  17. https://docs.microsoft.com/en-us/windows-server/networking/sdn/azure_and_sdn

63 visningar0 kommentarer

Senaste inlägg

Visa alla

Comments


Post: Blog2_Post
bottom of page