Zranitelnosti všude, kam se pohlédne

4. 12. 2016

Sdílet

 Autor: © koltukov - Fotolia.com
Nástup do nového zaměstnání, kde máte na starosti zabezpečení, může být zdrcující – vidíte problémy všude. Musíte se zaměřit na nejdůležitější oblasti provozu a rozhodnout, jaká zlepšení jsou nutná jako první.

Při kontrole způsobu zabezpečení v mém novém zaměstnání nacházím problémy se zabezpečením prakticky všude. Nejprve jsem si všiml toho, že moje bezdotyková přístupová karta byla prázdná: žádná fotografie, žádné jméno, žádný zřetelný symbol, který by ukazoval, že jsem zaměstnancem.

Zmínil jsem to lidem z personálního oddělení, ale koncept personalizovaných přístupových karet jim byl cizí. Připomněl jsem jim příběh jiné společnosti – vetřelec se k jedné takové neoznačené kartě dostal, prohlásil, že je nový pracovník IT pro podporu desktopů, a odešel se všemi nezajištěnými notebooky, které mohl unést. Ukradená karta vypadala stejně jako všechny ostatní vydané u této společnosti, a proto lidem, s nimiž se setkával při krádeži, neřekla absolutně nic.

Také jsem našel dveře do datového centra, které byly zabezpečené klíčem namísto přístupovou kartou a biometrií. U východových dveří ve vstupní hale jsou sice kamery, ale nikdo nemonitoruje jejich obraz a záznamy se neuchovávají. I když bylo snadné najít mezery ve fyzickém zabezpečení, má hlavní pozornost se musí obrátit na zabezpečení dat. A zde je také mnoho záležitostí, se kterými budu mít spousty práce.

 

Problémy s API

Dobrým místem pro start je oblast, kde firma působí: psaní softwaru, který je zákazníkům k dispozici přes cloud a webové prohlížeče. Naše API (konkrétně REST API) je klientům volně k dispozici, aby mohli rozšířit funkčnost našeho softwaru pomocí webových služeb a integrovat své aplikace vlastní nebo třetích stran s našimi produkty.

Když zákazníci chtějí integrovat další aplikaci s naším softwarem, nainstalují si toto rozhraní na svém serveru. To se autentizuje pro naši aplikaci a přenáší obousměrně data. Způsob, jakým se API autentizuje, je podobný autentizaci osob, takže zde existují podobné problémy se zabezpečením. Silná autentizace, oprávnění, šifrování a ověření dat jsou jen některými z bezpečnostních kontrol, které musejí být implementované. Chtěl jsem vědět, zda tomu tak je.

Při kontrole několika konfigurací, které zákazníci používali, jsem si například všiml, že mnoho integrací API nebylo omezeno IP adresou. Jsem velkým zastáncem pravidla minimálních oprávnění a i u API je to stejné. Pokud je kód API umístěn na serverech zákazníka, pak by jeho volání mělo být povolené jen z těchto serverů a všechny ostatní IP adresy by měly být zakázané. Je to velmi jednoduchá konfigurace, která je velmi podobná tomu, co používáme pro uživatelské účty.

Další mnou nalezený problém se týkal účtů webových služeb, které byly vázané na osobu. Účty webových služeb by měly být vázané na nezávislý systémový účet, a ne na osobu. Lidé odcházejí, a když se to stane, měly by se jejich účty smazat. Když smazání jednoho z těchto účtů ovlivní integraci API, vznikne problém.

Moje kontrola ale našla jedno světlé místo: Šifrování při přenosech máme v pořádku, protože pro všechna spojení se používá vynucení protokolu HTTPS (tzv. SSL Everywhere).

ICTS24

 

Tento příspěvek do Zápisníku manažera pro bezpečnost napsal skutečný manažer bezpečnosti, který zde vystupuje jako Mathias Thurman. Jeho pravé jméno ani jméno zaměstnavatele z pochopitelných důvodů neuvádíme.