Redigera

Dela via

Säkerhetsaspekter för mycket känsliga IaaS-appar i Azure

Azure Disk Encryption
Azure Firewall
Azure Key Vault
Microsoft Defender for Cloud
Azure Virtual Network

Det finns många säkerhetsöverväganden för att distribuera IaaS-appar (infrastruktur som en tjänst) till Azure. Den här artikeln bygger på referensarkitekturer för virtuella datorbaserade arbetsbelastningar och hybridnätverksinfrastrukturer för att fokusera på säkerhet för mycket känsliga IaaS-arbetsbelastningar i Azure, baserat på grunderna i Azure-säkerhet.

Se även Säkerhetsöversikt för virtuella Azure-datorer och Metodtips för säkerhet för IaaS-arbetsbelastningar i Azure.

Virtuella Azure-datorer

Azures beräkningsplattform baseras på datorvirtualisering. Ett hypervisor-program körs på den fysiska maskinvaran för varje Azure-nod eller nätverksslutpunkt och skapar ett variabelt antal virtuella Hyper-V-gästdatorer i noden. All användarkod körs på de virtuella datorerna. Grundläggande distributionsinstruktioner för virtuella Azure-datorer finns i Köra en virtuell Linux-dator på Azure eller Kör en virtuell Windows-dator på Azure. De flesta distributionsprocesser är desamma för de två operativsystemen ,men OS-specifika verktyg som diskkryptering kan skilja sig åt.

Du kan använda Microsoft Defender för molnet för hantering av VM-korrigeringar och för att distribuera och övervaka verktyg mot skadlig kod. Du kan också hantera dina egna eller tredje parts korrigerings- och program mot skadlig kod, vilket är vanligt när du utökar eller migrerar befintliga infrastrukturer till Azure.

Microsoft tillhandahåller grundläggande DDoS-skydd (Distribuerad överbelastning) som en del av Azure-plattformen. Appar som har offentliga slutpunkter kan använda Standard Azure DDoS Protection för ytterligare skydd. Mycket känsliga arbetsbelastningar har dock vanligtvis inte offentliga slutpunkter och kan bara nås från specifika platser via ett virtuellt privat nätverk (VPN) eller en hyrd linje.

N-nivåarkitekturer

Många IaaS-program består av flera nivåer, till exempel en webbnivå, affärsnivå och datanivå, som finns på flera virtuella datorer. Viktiga aspekter av att distribuera n-nivåapparkitekturer på virtuella Azure-datorer är:

  • Hög tillgänglighet (HA). HA-appar måste vara tillgängliga mer än 99,9 % av tiden. Om du placerar virtuella datorer på nivå i olika Azure-tillgänglighetszoner säkerställs tillgänglighetszoner eftersom tillgänglighetszoner omfattar ett eller flera datacenter, vilket ger återhämtning genom motståndskraft mot datacenterfel. Regioner som inte stöder tillgänglighetszoner kan använda tillgänglighetsuppsättningar som distribuerar virtuella datorer över flera isolerade maskinvarunoder.
  • Belastningsutjämning. Lastbalanserare distribuerar trafik mellan virtuella datorer för att balansera belastning och återhämtning när en virtuell dator misslyckas. Du behöver inte lastbalanserare om programmet hanterar belastningsutjämning och de enskilda virtuella datorerna är kända för anroparen.
  • Virtuella nätverk. Virtuella nätverk och undernät segmenterar nätverket, vilket möjliggör enklare säkerhetshantering och avancerad routning.
  • Domain Name System (DNS). Azure DNS tillhandahåller en högtillgänglig och säker DNS-tjänst. Med en privat zon i Azure DNS kan du använda anpassade domäner i dina virtuella nätverk.

Säkerhetskopiering och återställning

För att skydda mot mänskliga fel, borttagning av skadliga data och utpressningstrojaner bör du säkerhetskopiera minst dina virtuella datorer på datanivå. Azure Backup kan säkerhetskopiera och återställa krypterade virtuella datorer om de har åtkomst till krypteringsnycklarna i Azure Key Vault.

På webb- och affärsnivå kan du använda regler för automatisk skalning av vm-skalningsuppsättningar för att automatiskt förstöra komprometterade virtuella datorer och distribuera nya VM-instanser från en basavbildning.

Beräkningsisolering

På varje Azure-nod eller nätverksslutpunkt ser hypervisor-programmet och ett särskilt rotoperativsystem till att virtuella gästdatorer inte kan komma åt den fysiska värdservern och att användarkoden endast körs på virtuella gästdatorer. Den här isoleringen hindrar användare från att hämta rå läs-, skriv- eller körningsåtkomst till systemet och minskar risken för att dela resurser. Azure skyddar mot alla kända sidokanalattacker och bullriga grannar via hypervisor-programmet och en avancerad algoritm för vm-placering. Mer information finns i Beräkningsisolering.

För mycket känsliga arbetsbelastningar kan du lägga till ytterligare skydd mot sidokanalattacker med isolerade virtuella datorer eller dedikerade värdar.

Isolerade virtuella datorer

Isolerade virtuella datorer är stora VM-storlekar som är isolerade till en viss maskinvarutyp och dedikerade till en enda kund. Att använda en isolerad VM-storlek garanterar att den virtuella datorn är den enda som körs på en specifik serverinstans. Du kan dela upp resurserna för isolerade virtuella datorer ytterligare med hjälp av Azure Support för kapslade virtuella datorer.

Den minsta storleken på en isolerad virtuell dator är 64 virtuella CPU-kärnor och 256 GiB minne. Dessa virtuella datorer är mycket större än de flesta n-nivåprogram kräver och kan skapa stora kostnader. För att minska kostnaderna kan du köra flera appnivåer på en enda virtuell dator med kapslad virtualisering eller i olika processer eller containrar. Du behöver fortfarande distribuera olika virtuella datorer i tillgänglighetszoner för återhämtning och köra demilitariserade zoninstallationer (DMZ) på separata virtuella datorer. Att kombinera flera appar i en infrastruktur av ekonomiska skäl kan också vara i konflikt med organisationens appsegregeringsprinciper.

När funktionerna i Azure-regionen utökas över tid kan Azure också ta bort isoleringsgarantier från vissa VM-storlekar, med ett års varsel.

Azure Dedicated Hosts

Azure Dedicated Host är den föredragna lösningen för beräkningsisolering för mycket känsliga arbetsbelastningar. En dedikerad värd är en fysisk server som är dedikerad till en kund för att vara värd för flera virtuella datorer. Förutom att isolera virtuella datorer kan dedikerade värdar styra underhåll och placering av virtuella datorer för att undvika bullriga grannar.

Dedikerade värdar

Dedikerade värdar har samma minsta storlek och många av samma storleksöverväganden som isolerade virtuella datorer. En dedikerad värd kan dock vara värd för virtuella datorer som finns i olika virtuella nätverk för att uppfylla programsegregeringsprinciper. Du bör fortfarande köra virtuella DMZ-datorer på en annan värd för att förhindra sidokanalattacker från en komprometterad virtuell dator i DMZ.

Kryptering

Datakryptering är en viktig komponent för att skydda arbetsbelastningar. Kryptering kodar information så att endast auktoriserade mottagare kan avkoda den med hjälp av en nyckel eller ett certifikat. Kryptering omfattar diskkryptering, för datakryptering i vila och TLS (Transport Level Security) för kryptering under överföring över nätverk.

Azure Key Vault

Du kan skydda krypteringsnycklar och certifikat genom att lagra dem i Azure Key Vault, en HSM-lösning (Hardware Security Module) i molnet som verifierats för FIPS (Federal Information Processing Standards) 140-2 Level 2. Metodtips för att endast tillåta auktoriserade program och användare att komma åt Key Vault finns i Säker åtkomst till ett nyckelvalv.

För att skydda nycklar i Key Vault kan du aktivera mjuk borttagning, vilket säkerställer att borttagna nycklar kan återställas. För ytterligare skydd kan du säkerhetskopiera enskilda nycklar till en krypterad fil som du kan använda för att återställa nycklarna, eventuellt till en annan Azure-region i samma geografiska område.

När du är värd för SQL Server på en virtuell dator kan du använda SQL Server-anslutning för Microsoft Azure Key Vault för att hämta nycklar för transparent datakryptering (TDE), kryptering på kolumnnivå (CLE) och kryptering för säkerhetskopiering. Mer information finns i Konfigurera Azure Key Vault-integrering för SQL Server på virtuella Azure-datorer.

Azure Disk Encryption

Azure Disk Encryption använder ett bitLocker-skydd för externa nycklar för att tillhandahålla volymkryptering för operativsystemet och datadiskarna på virtuella Azure-datorer och kan integreras med Azure Key Vault för att hjälpa dig att styra och hantera diskkrypteringsnycklar och hemligheter. Varje virtuell dator genererar sina egna krypteringsnycklar och lagrar dem i Azure Key Vault. Information om hur du konfigurerar Azure Key Vault för att aktivera Azure Disk Encryption finns i Skapa och konfigurera ett nyckelvalv för Azure Disk Encryption.

För mycket känsliga arbetsbelastningar bör du också använda en nyckelkrypteringsnyckel (KEK) för ytterligare ett säkerhetslager. När du anger en KEK använder Azure Disk Encryption den nyckeln för att omsluta krypteringshemligheterna innan du skriver till Key Vault. Du kan generera en KEK i Azure Key Vault, men en säkrare metod är att generera en nyckel i din lokala HSM och importera den till Azure Key Vault. Det här scenariot kallas ofta BYOK (Bring Your Own Key). Eftersom de importerade nycklarna inte kan lämna HSM-gränsen ser genereringen av nyckeln i HSM till att du har fullständig kontroll över krypteringsnycklarna.

HSM-skyddad kryptering

Mer information om HSM-skyddade nycklar finns i Generera och överföra HSM-skyddade nycklar för Azure Key Vault.

Kryptering av nätverkstrafik

Nätverksprotokoll som HTTPS krypterar data under överföring med certifikat. Trafik från klient till program använder vanligtvis ett certifikat från en betrodd certifikatutfärdare (CA). Interna appar kan använda ett certifikat från en intern certifikatutfärdare eller en offentlig certifikatutfärdare som DigiCert eller GlobalSign. Nivå-till-nivå-kommunikation använder vanligtvis ett certifikat som utfärdats av en intern certifikatutfärdare eller ett självsignerat certifikat. Azure Key Vault kan hantera någon av dessa certifikattyper. Mer information om hur du skapar olika certifikattyper finns i Metoder för att skapa certifikat.

Azure Key Vault kan fungera som en självsignerad certifikatutfärdare för nivå-till-nivå-trafik. Tillägget för den virtuella Key Vault-datorn ger övervakning och automatisk uppdatering av angivna certifikat på virtuella datorer, med eller utan den privata nyckeln beroende på användningsfall. Information om hur du använder tillägget för den virtuella Key Vault-datorn finns i Tillägget för virtuella Key Vault-datorer för Linux eller Key Vault för Windows.

Key Vault kan också lagra nycklar för nätverksprotokoll som inte använder certifikat. Anpassade arbetsbelastningar kan kräva skript för ett anpassat skripttillägg som hämtar en nyckel från Key Vault och lagrar den för program att använda. Appar kan också använda en virtuell dators hanterade identitet för att hämta hemligheter direkt från Key Vault.

Nätverkssäkerhet

Nätverkssäkerhetsgrupper (NSG:er) filtrerar trafik mellan resurser i virtuella Azure-nätverk. NSG-säkerhetsregler tillåter eller nekar nätverkstrafik till eller från Azure-resurser baserat på IP-adresser och portar. Som standard blockerar NSG:er inkommande trafik från Internet, men tillåter utgående anslutningar från virtuella datorer till Internet. För att förhindra oavsiktlig utgående trafik lägger du till en anpassad regel med lägsta möjliga prioritet, 4096, för att blockera all inkommande och utgående trafik. Du kan sedan lägga till regler med högre prioritet för att tillåta specifik trafik.

NSG:er skapar flödesposter för befintliga anslutningar och tillåter eller nekar kommunikation baserat på flödespostens anslutningstillstånd. Med flödesposten kan en NSG vara tillståndskänslig. Om du till exempel anger en utgående säkerhetsregel till en adress via port 443, är det inte nödvändigt att även ange en inkommande säkerhetsregel för svaret. Du behöver bara ange en regel för inkommande säkerhet om kommunikationen initieras externt.

Med de flesta Azure-tjänster kan du använda en tjänsttagg för virtuellt nätverk i stället för en NSG. En tjänsttagg representerar en grupp IP-adressprefix från en Azure-tjänst och hjälper till att minimera komplexiteten från frekventa uppdateringar av nätverkssäkerhetsregler. En Azure Key Vault-tjänsttagg kan tillåta att en virtuell dator hämtar certifikat, nycklar och hemligheter från Azure Key Vault.

Ett annat sätt att kontrollera nätverkssäkerheten är via trafikroutning och tvingad tunneltrafik i virtuella nätverk. Azure skapar automatiskt systemvägar och tilldelar vägarna till varje undernät i ett virtuellt nätverk. Du kan inte skapa eller ta bort systemvägar, men du kan åsidosätta vissa systemvägar med anpassade vägar. Med anpassad routning kan du dirigera trafik över en virtuell nätverksinstallation (NVA) som en brandvägg eller proxy eller släppa oönskad trafik, vilket har en liknande effekt som att blockera trafiken med en NSG.

Du kan använda NVA:er som Azure Firewall för att tillåta, blockera och inspektera nätverkstrafik. Azure Firewall är en hanterad plattformsbrandväggstjänst med hög tillgänglighet. Du kan också distribuera nva från tredje part från Azure Marketplace. Information om hur du gör dessa NVA:er mycket tillgängliga finns i Distribuera virtuella nätverksinstallationer med hög tillgänglighet.

Programsäkerhetsgrupper

Om du vill filtrera trafik mellan programnivåer i ett virtuellt nätverk använder du Programsäkerhetsgrupper (ASG). Med ASG:er kan du konfigurera nätverkssäkerhet som ett tillägg till ett programs struktur, så att du kan gruppera virtuella datorer och definiera nätverkssäkerhetsprinciper baserat på grupperna. Du kan återanvända din säkerhetsprincip i stor skala utan att manuellt underhålla explicita IP-adresser.

Programsäkerhetsgrupper

Eftersom ASG:er tillämpas på ett nätverksgränssnitt i stället för ett undernät aktiverar de mikrosegmentering. Du kan kontrollera vilka virtuella datorer som kan kommunicera med varandra, till och med blockera trafik mellan virtuella datorer på samma nivå och göra det enkelt att placera en virtuell dator i karantän genom att ta bort ASG:er från den virtuella datorn.

Hybridnätverk

Hybridarkitekturer ansluter lokala nätverk med offentliga moln som Azure. Det finns flera sätt att ansluta lokala nätverk till program som körs i Azure:

  • Offentlig slutpunkt via Internet. Du kan lita på identitet, säkerhet på transportnivå (HTTPS) och programgatewayen för att skydda programmet, eventuellt i kombination med en brandvägg. För mycket känsliga arbetsbelastningar rekommenderas dock inte att exponera en offentlig slutpunkt via Internet.
  • Azure eller VPN-gateway från tredje part. Du kan ansluta ett lokalt nätverk till Azure med hjälp av en Azure VPN-gateway. Trafiken färdas fortfarande via Internet, men över en krypterad tunnel som använder TLS. Du kan också köra en gateway från tredje part på en virtuell dator om du har specifika krav som inte stöds av Azure VPN-gatewayen.
  • ExpressRoute. Med ExpressRoute-anslutningar används en privat, dedikerad anslutning via en utomstående anslutningsleverantör. Den privata anslutningen utökar ditt lokala nätverk till Azure och ger skalbarhet och ett tillförlitligt serviceavtal (SLA).
    • ExpressRoute med VPN-redundans. Det här alternativet använder ExpressRoute under normala förhållanden, men redundansväxlar över till en VPN-anslutning om anslutningen går förlorad i ExpressRoute-kretsen, vilket ger högre tillgänglighet.
    • VPN via ExpressRoute. Det här alternativet är det bästa för mycket känsliga arbetsbelastningar. ExpressRoute tillhandahåller en privat krets med skalbarhet och tillförlitlighet, och VPN ger ytterligare ett skyddslager som avslutar den krypterade anslutningen i ett specifikt virtuellt Azure-nätverk.

Mer information om hur du väljer mellan olika typer av hybridanslutningar finns i Välja en lösning för att ansluta ett lokalt nätverk till Azure.

Distribuera en DMZ

Anslutning av lokala miljöer och Azure-miljöer ger lokala användare åtkomst till Azure-program. Ett perimeternätverk eller en demilitariserad zon (DMZ) ger ytterligare skydd för mycket känsliga arbetsbelastningar.

En arkitektur som den i Nätverks-DMZ mellan Azure och ett lokalt datacenter distribuerar alla DMZ- och programtjänster i samma virtuella nätverk, med NSG-regler och användardefinierade vägar för att isolera DMZ- och programundernäten. Den här arkitekturen kan göra hanteringsundernätet tillgängligt via offentligt Internet för att hantera appar även om den lokala gatewayen inte är tillgänglig. För mycket känsliga arbetsbelastningar bör du dock bara tillåta att gatewayen kringgås i ett scenario med brytglas. En bättre lösning är att använda Azure Bastion, som ger åtkomst direkt från Azure Portal samtidigt som exponeringen för offentliga IP-adresser begränsas.

Du kan också använda JIT-åtkomst (Just-In-Time) för fjärrhantering samtidigt som exponeringen för offentliga IP-adresser begränsas. Med JIT VM-åtkomst blockerar en NSG fjärrhanteringsportar som RDP (Remote Desktop Protocol) och SSH (Secure Shell) som standard. På begäran aktiverar JIT VM-åtkomst porten endast för ett angivet tidsfönster och eventuellt för en specifik IP-adress eller ett visst intervall. JIT-åtkomst fungerar också för virtuella datorer som bara har privata IP-adresser. Du kan använda Azure Bastion för att blockera trafik till en virtuell dator tills JIT VM-åtkomst har aktiverats.

Om du vill distribuera fler program kan du använda en nätverkstopologi för hub-spoke i Azure, med DMZ i det virtuella hubbnätverket och programmen i virtuella ekernätverk. Det virtuella hubbnätverket kan innehålla en VPN- och/eller ExpressRoute-gateway, brandväggs-NVA, hanteringsvärdar, identitetsinfrastruktur och andra delade tjänster. De virtuella ekernätverken är anslutna till hubben med peering för virtuella nätverk. Ett virtuellt Azure-nätverk tillåter inte transitiv routning över hubben från en eker till en annan. Spoke-to-spoke-trafik är endast möjligt via brandväggsinstallationerna i hubben. Den här arkitekturen isolerar effektivt program från varandra.

Distribution i flera regioner

Affärskontinuitet och haveriberedskap kan kräva distribution av ditt program i flera Azure-regioner, vilket kan påverka datahemvist och säkerhet. En referensarkitektur för distributioner i flera regioner finns i Köra ett N-nivåprogram i flera Azure-regioner för hög tillgänglighet.

Regionala par

Ett Geografiskt Azure-område är ett definierat område i världen som innehåller minst en Azure-region, var och en med ett eller flera datacenter. Varje Azure-region paras ihop med en annan region i samma geografi i ett regionalt par. Regionala par uppdateras inte samtidigt, och om en katastrof drabbar båda regionerna prioriteras en av regionerna att komma tillbaka online först. För affärskontinuitet bör du distribuera mycket känsliga appar åtminstone till regionala par om du distribuerar i flera regioner.

Mer information finns i Affärskontinuitet och haveriberedskap (BCDR): Azure-kopplade regioner. Vitboken Uppnå kompatibel datahemvist och säkerhet med Azure diskuterar datahemvist och vad du ska göra för att uppfylla kraven på datahemvist.

Replikering mellan regioner

I IaaS-arkitekturer är det programmets ansvar att replikera data mellan regioner. Det vanligaste replikeringsscenariot använder databasreplikeringstekniker som är inbyggda i databasserverprodukten, till exempel SQL Server AlwaysOn-tillgänglighetsgrupper, Oracle Data Guard eller MySQL Replication.

Det är inte enkelt att konfigurera replikering mellan IaaS-databasservrar och du måste ta hänsyn till kraven på affärskontinuitet. Azure-databastjänster som Azure SQL Database, Azure Database for MySQL och Azure Cosmos DB gör replikering mellan regioner enklare, men uppfyller kanske inte säkerhetskrav för mycket känsliga arbetsbelastningar.

Mer information och vägledning för SQL Server- och Oracle-distributioner i flera regioner finns i:

Peering mellan regioner

Du kan aktivera säker kommunikation mellan virtuella nätverk i olika regioner med hjälp av global peering för virtuella nätverk. Global peering fungerar på samma sätt som peering inom regionen. Trafiken mellan regioner körs över Microsofts stamnät, passerar inte internet och är isolerad från annan trafik. För mer säkerhet kan du distribuera VPN NVA:er i båda regionerna och använda användardefinierade vägar för att tvinga trafik mellan regioner över nva:erna, ungefär som att distribuera en DMZ.

Routning av redundanstrafik

Med offentliga slutpunkter kan du använda Traffic Manager eller Azure Front Door för att dirigera trafik till den aktiva regionen eller närmaste regionen i en aktiv-aktiv redundanskonfiguration. Traffic Manager och Azure Front Door kräver dock båda offentliga slutpunkter för att övervaka tillgängligheten, och deras motsvarande DNS-poster är offentliga. För mycket känsliga arbetsbelastningar är den alternativa lösningen att distribuera DNS lokalt och ändra posterna till den aktiva regionen för redundans.

Hantering och styrning

Att skydda dina mycket känsliga IaaS-appar kräver mer än att bara distribuera rätt arkitekturer och implementera nätverkssäkerhetsregler. Eftersom molnmiljöer enkelt ändras är det särskilt viktigt att se till att ändringar endast kan göras med vissa behörigheter och inom gränserna för säkerhetsprinciper. Du måste till exempel förhindra att en obehörig aktör kan ändra en nätverkssäkerhetsregel för att tillåta trafik från Internet.

För att distribuera arbetsbelastningar i Azure behöver du ett eller flera hanteringskonton. Det är viktigt att skydda hanteringskonton för att skydda dina arbetsbelastningar. Mer information finns i Skydda privilegierad åtkomst för hybrid- och molndistributioner i Microsoft Entra-ID.

Använd resurserna i ditt hanteringsundernät för att endast bevilja åtkomst på appnivå till personer som behöver hantera den nivån. Du kan till exempel använda Microsoft Identity Manager med Microsoft Entra-ID. För molnbaserade scenarier föredras dock Microsoft Entra Privileged Identity Management (PIM).

Det finns flera andra sätt att styra Azure-roller och -principer:

  • Med rollbaserad åtkomstkontroll i Azure (Azure RBAC) för Azure-resurser kan du tilldela inbyggda eller anpassade roller till användare, så att de bara har de behörigheter de behöver. Du kan kombinera Azure RBAC med PIM för att implementera ett granskningsarbetsflöde för godkännande som höjer behörigheter under en begränsad tidsperiod.
  • Principer tillämpar företagets regler, standarder och serviceavtal. Azure Policy är en Azure-tjänst som skapar, tilldelar och hanterar principer och utvärderar dina resurser för principefterlevnad.
  • Azure Blueprints kombinerar rolltilldelningar, principtilldelningar och distributionsmallar för att definiera en uppsättning replikerbara Azure-resurser som implementerar och följer organisationens standarder, mönster och krav. Skisser är ett deklarativt sätt att samordna distributionen av resursmallar och andra artefakter. Du kan skapa skisser själv eller använda befintliga skisser. Till exempel distribuerar ISO 27001 Shared Services-skissen en hubb för delade tjänster som du kan ändra och utöka till organisationens krav.

Övervakning

Microsoft Defender för molnet tillhandahåller övervakning och aviseringar som hjälper dig att upprätthålla säkerheten i din miljö. Den kostnadsfria tjänsten söker automatiskt efter säkerhetsrisker, till exempel saknade os-korrigeringar, felkonfiguration av säkerhet och grundläggande nätverkssäkerhet. Den betalda standardversionen ger dig ytterligare funktioner, till exempel beteendeanalys, adaptiv nätverkshärdning och JIT VM-åtkomst. En fullständig lista över funktioner finns i Funktionstäckning för datorer. Defender för molnet ger även skydd mot hot för andra resurser som Azure Key Vault.

Du kan använda Azure Monitor för ytterligare övervakning och analys. Om du vill övervaka identitet och åtkomst kan du dirigera Microsoft Entra-aktivitetsloggar till Azure Monitor. Du kan också övervaka virtuella datorer, nätverk och Azure Firewall och analysera importerade loggar med kraftfull loggfrågefunktion . Du kan integrera Azure Monitor med din Säkerhetsinformation och Event Manager (SIEM) som kan vara en SIEM från tredje part eller Microsoft Sentinel.