Přihlašujte se do Linux VM v Azure s AAD a třeba i vícefaktorově

Při vytváření VM v Azure specifikujete přihlašovací údaje administrátora. Tímto účtem se připojíte a řešíte to dál. Možná přidáte účty pro vaše kolegy, ale pokud máte takových VM sto a jeden z účtů je kompromitovaný (nebo ten člověk u vás už nepracuje), je dost práce to změnit. Linux s tím počítá a přes PAM (Pluggable Authentication Module) může OS napojit na centrální repozitář, typicky LDAP nebo standardní AD. Proč ale nevyužít úžasných vlastností Azure Active Directory včetně vícefaktoru, kontroly klienstkého zařízení, analýzy rizika nebo řízení eskalace oprávnění? Pokračovat ve čtení „Přihlašujte se do Linux VM v Azure s AAD a třeba i vícefaktorově“

Jak aktivovat bezpečnou vzdálenou správu Windows s WinRM a Azure Key Vault

Klasické nasazení Windows VM v Azure funguje tak, že aktivujete RDP, připojíte se do VM a uděláte co potřebujete (třeba zapnete WinRM, začleníte server do domény apod.). Půlroční releasy Windows 2016 už ale nepřichází s kompletním GUI, takže se přes RDP stejně napojíte rovnou na PowerShell a odtamtud pokračujete dál. Jak tenhle krok přeskočit a rovnou zprovoznit správu přes WinRM a Admin Center hned v rámci deploymentu? Pokračovat ve čtení „Jak aktivovat bezpečnou vzdálenou správu Windows s WinRM a Azure Key Vault“

Chcete maximální bezpečnost v Azure i jinde? Přemýšlejte o privilegované pracovní stanici.

Pokud je bezpečnost správy systémů (OS, DB, …) pro vás to nejdůležitější, zvažte použití privilegované pracovní stanice. Možná to není pro administrátory zrovna pohodlné a flexibilní, ale je to skvělý způsob dramatického zvýšení bezpečnosti. Dnes si řekneme proč a jak to funguje a v dalším díle si vyzkoušíme některé příklady, například velmi zajímavý projekt Apache Guacamole. Pokračovat ve čtení „Chcete maximální bezpečnost v Azure i jinde? Přemýšlejte o privilegované pracovní stanici.“

Jak oddělit správu hesel od nasazení Azure infrastruktury a aplikací s Azure Key Vault

Představte si, že Azure pro vás spravuje provozák, který má mít schopnost prostředí zakládat, ale neměl by znát heslo do databáze. MySQL služba nepoužívá Azure Active Directory pro ověřování, takže při jejím vytváření potřebujeme nějaké heslo určit. Stejně tak při konfiguraci aplikace potřebujeme skočit do VM a do konfiguračního souboru aplikace zadat heslo do databáze. Situace je tedy neřešitelná – provozák to heslo zkrátka mít musí… nebo ne? Jasně že ne – uložme si hesla do trezoru s Azure Key Vault. Pokračovat ve čtení „Jak oddělit správu hesel od nasazení Azure infrastruktury a aplikací s Azure Key Vault“

Jak navrhnout FW pravidla v Azure s NSG a ASG

Pokud z nějakého důvodu nemůžete použít platformní službu (PaaS), možná stojíte před úkolem jak nastavit firewall pravidla pro aplikaci ve VM, která má dvojici webových serverů přístupných z venku a dvě databázové VM. Jak to udělat? Mikrosegmentace per VM? Nebo pravidla na subnet? A co aplikační objekty s ASG? Podívejme se dnes na čtyři způsoby jak to navrhnout a výhody či nevýhody každého z nich. Pokračovat ve čtení „Jak navrhnout FW pravidla v Azure s NSG a ASG“

Ochraňte svojí aplikaci v Azure s WAF a Security Center

Máte v infrastrukturní službě v Azure nasazenou aplikaci ve VM a chcete ji chránit před útoky na úrovni protokolu a aplikace jako SQL injection a podobně? Nebo chcete využít veřejného endpointu v cloudu pro ochranu vaší on premise aplikace? Podívejme se, jak Azure Security Center mimo jiné umí automatizovaně nasadit bezpečnostní řešení různých firem (Microsoft, F5, Imperva, Barracuda či Fortinet) – vytvořit i nakonfigurovat tak, že nemusíte být expertem na zmíněné technologie na to, abyste začali svou aplikaci chránit. Pokračovat ve čtení „Ochraňte svojí aplikaci v Azure s WAF a Security Center“

Přístup k PaaS SQL nebo Storage z vnitřní sítě Azure VNet

Platformní služby mají velmi příjemné vlastnosti z hlediska funkcí, ale i škály a cenové dostupnosti. To ale typicky znamená, že pro využití výnosů z rozsahu jsou některé jejich komponenty multi-tenantní – například jejich interní balancer apod. To znemožňuje nebo znesnadňuje (prodražuje) jejich instalaci ve VNET, privátní síti. Většinou to nevadí. Někdy ale chcete ke službám přistupovat z VNETu. Dnes už je to řešitelné – podívejme jak. Pokračovat ve čtení „Přístup k PaaS SQL nebo Storage z vnitřní sítě Azure VNet“

Just-in-time access bezpečnost s Azure Security Center

Většina administrátorů chce mít možnost připojit se do VM v případě, že se děje něco špatného a ručně zasáhnout. Proto vyžaduje síťově otevřený přístup na SSH, RDP, VNC nebo WinRM port. Tomu velmi rozumím, ale proč nechávat port otevřený i při běžném provozu zbytečně a vystavovat se riziku pokusů o průnik? Co kdyby ho váš firewall blokoval, ale když ho opravdu potřebujete, tak vám ho virtuální síťový kolega třeba na hodinu povolí a pak zas uzavře?

Just in time access v Azure Security Center

Bezpečnostní centrum v Azure disponuje celou řadou monitorovacích a zabezpečovacích mechanismů a just in time access je novinkou. Je to vlastně velmi jednoduché. V Azure není firewall nějaká externí krabice od které má klíče jen vyvolený síťař či bezpečák, ale jde o objekt spravovaný jako všechny ostatní zdroje v Azure Resource Manager. Služba Azure Security Center tedy může jednoduše automatizovat firewallová pravidla na VM a jednoduše povolit na omezený čas přístup do VM na vyžádání.

Azure Security Center má základní verzi zdarma, ta ale neobsahuje funkci just in time access. Můžete si ji vyzkoušet v 60 denním trial nebo pořídit kompletní Azure Security Center včetně threat intelligence, behaviorální analýzy, detekce anomálií a dalších funkcí za 12,65 EUR za VM a měsíc.

Vytvoříme si VM se výchozím firewallem (NSG), který povoluje management přístup (v mém případě s Linux na port 22 čili SSH, u Windows na port 3389, tedy RDP).

$ az group create -n jit -l westeurope
$ az vm create -n jitvm -g jit --image UbuntuLTS --authentication-type password --admin-username tomas --admin-password MojeHeslo123

SSH přístup k této VM bude fungovat.

$ ssh 23.97.217.128
tomas@23.97.217.128's password:

Nastavíme si Just in time access. Jde o funkci, která je součástí Azure Security Center.

V centru zabezpečení klikněte na Just in time.

Povolíme Just in time přístup pro tuto VM.

V následném dialogu nastavíme politiku pro zpřístupňování portů – typicky to budou ty pro správu jako je SSH, RDP, WinRM apod. U každého můžeme nastavit několik parametrů. Jedním z nich je filtrace podle zdrojové adresy, kde můžeme zadat konkrétní rozsah (například pro vnitřní privátní adresy nebo blok veřejných IP vaší firmy) nebo použít konkrétní zdrojovou IP z požadavku. Dále také zadáme maximální čas otevření portu pro jeden požadavek.

V tento okamžik Azure automaticky zavřel SSH přístup do VM.

$ ssh 23.97.217.128
ssh: connect to host 23.97.217.128 port 22: Resource temporarily unavailable

Podívejme se na network security group přiřazenou na VM. Azure Security Center přidalo Deny pravidla pro nastavené porty.

"securityRules": [
   {
     "access": "Deny",
     "description": "ASC JIT Network Access rule for policy 'default' of VM 'jitvm'.",
     "destinationAddressPrefix": "10.0.0.4",
     "destinationPortRange": "22",
     "direction": "Inbound",
     "etag": "W/\"3d41b84b-6610-4dbe-b49c-92b238b1314b\"",
     "id": "/subscriptions/a0f4a733-4fce-4d49-b8a8-d30541fc1b45/resourceGroups/jit/providers/Microsoft.Network/networkSecurityGroups/jitvmNSG/securityRules/SecurityCenter-JITRule_-1058539234_CECD5346BB6D4380AA484CE870B283EE",
     "name": "SecurityCenter-JITRule_-1058539234_CECD5346BB6D4380AA484CE870B283EE",
     "priority": 1000,
     "protocol": "*",
     "provisioningState": "Succeeded",
     "resourceGroup": "jit",
     "sourceAddressPrefix": "*",
     "sourcePortRange": "*"
   },

Požádáme teď o otevření přístupu.

Zvolím pouze port 22 a stačí mi na jednu hodinu.

Po chvilce máme port otevřený.

$ ssh 23.97.217.128
tomas@23.97.217.128's password:

Security Center totiž změnilo příslušné pravidlo v NSG na Allow (všimněte si také, že tam je specificky moje zdrojová IP adresa) a teprve po vypršení stanovené doby to automaticky vrátí zpět na Deny.

"securityRules": [
    {
      "access": "Allow",
      "description": "ASC JIT Network Access rule created by an initiation request for policy 'default' of VM 'jitvm'.",
      "destinationAddressPrefix": "10.0.0.4",
      "destinationPortRange": "22",
      "direction": "Inbound",
      "etag": "W/\"4ae8c174-3af1-4f27-8fad-4551169d3a9d\"",
      "id": "/subscriptions/a0f4a733-4fce-4d49-b8a8-d30541fc1b45/resourceGroups/jit/providers/Microsoft.Network/networkSecurityGroups/jitvmNSG/securityRules/SecurityCenter-JITRule--1058539234-21FC05A217E044D59AB6A0D394376920",
      "name": "SecurityCenter-JITRule--1058539234-21FC05A217E044D59AB6A0D394376920",
      "priority": 100,
      "protocol": "*",
      "provisioningState": "Succeeded",
      "resourceGroup": "jit",
      "sourceAddressPrefix": "90.181.122.97",
      "sourcePortRange": "*"
    },

Zažádat o přístup můžete nejen z GUI, ale také v PowerShellu. Stačí mít poslední verzi AzureRM commandletů a nainstalovat Azure Security Center modul:

Install-Module -Name Azure-Security-Center

Pak otevřete přístup k VM takhle:

Invoke-ASCJITAccess -ResourceGroupName jit -VM jitvm -Port 22

 

Azure díky softwarově definovaným principům a schopnosti automatizace umožňuje použít metody a techniky, které by v běžné infrastruktuře byly nepraktické. Jednou z nich je just in time přístup do VM. Vyskoušejte si i další vlastnosti Azure Security Center.

Azure Security Center: Update management aneb patchujte Windows i Linux

Azure Security Center (produkt, který postupně konsoliduje vlastnosti security v Azure a bezpečnostní analýzu OMS), nástroj pro hybridní správu vašeho datového centra i cloudu, nabízí schopnost přehledu chybějících aktulizací operačních systému Windows a Linux. Ujistěte se, že jsou vaše servery v dobrém stavu a můžete ASC využít i k inicializaci a plánování jejich patchování. Podívejme se dnes jak to funguje a proč je to užitečné. Pokračovat ve čtení „Azure Security Center: Update management aneb patchujte Windows i Linux“