Tak to je skvělé načasování! Byl jsem na konferenci RSA, kde jsem se soustředil na problematiku cloud computingu, a hned poté jsem byl přizván na firemní poradu, kde jsme prodiskutovávali náš první pokus o nasazení tohoto výpočetního modelu.
Naše oddělení IT se totiž rozhodlo pro kontrakt s poskytovatelem IaaS (Infrastructure-as-a-service, infrastruktura jako služba), v rámci kterého by došlo k hostingu části našeho vývojářského prostředí. Pokud se tento prvotní projekt vydaří, mohly by být na řadě některé další části našeho produkčního prostředí.
Protože jsem si k tomto tématu přečetl relativně dost informací z technické dokumentace a také jsem navštívil různé semináře, považoval jsem se za dostatečně obeznámeného, abych mohl klást otázky, které musí být zodpovězeny, abych mohl zůstat klidný ohledně iniciativy otevírající nové brány do naší sítě a k našim datům.
Zmíněný plán obsahuje myšlenku přesunout vlastní vývojářské prostředí pro prostředí SAPu do cloudu. Naši vývojáři obvykle testují aplikace se skutečnými produkčními daty. Když použijí finanční data na testovacím serveru našeho vlastního datového centra, nevzniká s tím žádný problém. Je však zcela něco jiného, pokud by takový server měl být umístěn někde daleko a mimo naši kontrolu. V tomto případě by totiž naše hostované servery byly ve skutečnosti umístěny v datovém centru příslušného poskytovatele hostingu.
Jsou zde tedy možné dvě úrovně separace. Plán zahrnuje konfiguraci několika virtuálních serverů s operačními systémy Linux a Windows ve sdíleném prostředí systému VMware ESX Server. Dodavatel cloudového řešení po nás požaduje vytvoření tunelu VPN (Virtual Private Network, virtuální privátní síť). Nejsem nijak nadšený z toho, že nebudeme mít kontrolu nad bodem, kde je VPN ukončena, a skutečnost, že tento uzel je tvořen linuxovým serverem využívajícím software VPN licencovaný jako open source, to nijak nemění.
Po zapracování mých poznámek pramenících z obavy o bezpečnost náš dodavatel chce, abychom používali sdílený klíč pro autentizaci VPN sestavené mezi zařízeními. Plánu povinného použití certifikátů při provádění autentizace jsem se bránil. Také jsem vytvořil pravidla pro firewall, která omezují servery z infrastruktury dodavatele v tom, aby nemohly přistupovat dále do naší sítě.
Snadné řešení
Potom jsem si vzal na mušku webově orientovanou správní aplikaci, kterou naši technici musí používat. Pokud srovnáte tuto aplikaci s naším současným řízením přístupu do datového centra, jsou zranitelnosti té nové tak velké, že by i dospělého manažera zabezpečení rozplakaly. Do této doby by záškodník musel znát fyzické umístění našeho datového centra, dále získat visačku opravňující k tomu, aby mohl do budovy vstoupit, dále aby se do datového centra dostal, musel by si sehnat ještě jednu další visačku a pak nějak přelstít biometrický skener - a také by musel přesně vědět, ve kterých rozvaděčích má hledat servery, jež si vyhlédl k útoku.
Ve srovnání s tím ona webová správní aplikace požaduje jen přihlašovací jméno a heslo, je přístupná odkudkoliv přes internet a navíc všichni zákazníci používají stejnou adresu URL. Jediná věc, kterou potom útočník potřebuje, je program zaznamenávající stisknuté klávesy (keystroke logger). A zde je ukázka, jak si náš dodavatel cení zabezpečení: Dává klientům dočasná hesla bez požadavku na jejich změnu po úvodním přihlášení a ani nevynucuje použití silných hesel.
Měl jsem samozřejmě ještě další otázky a odpovědi moji důvěru nijak nevzbuzovaly. Jak bychom se dozvěděli, pokud by došlo k neautorizované manipulaci s naším prostředím někým ze zaměstnanců, kdo by byl rozhněvaný nebo chtěl plánovitě udělat nějakou lumpárnu? „Hmm, no, to nás nikdy nenapadlo, ale naše nabídka je zaměřena výhradně na vývojová prostředí,“ byla jejich odpověď.
Dobře, jak je to tedy se šifrováním? „Protože poskytujeme služby pro vývojářská prostředí, radíme zákazníkům, aby citlivá produkční data ve vývojovém prostředí nepoužívali.“ Skutečně jejich zákazníci vytvářejí data z ničeho, nebo naopak spíše použijí ta, která mají už k dispozici v produkčním prostředí?
Závěrem je, že musíme ještě ujít dlouhou cestu, než budeme moci navázat důvěrný vztah mezi infrastrukturou poskytovatele cloud computingu a sítí naší firmy, protože v zabezpečení je ještě příliš mnoho oblastí, které je nutno u něj zlepšit.