Performance vs. Security

Wydajność kontra Bezpieczeństwo. Kto o tym myśli? Czy dzisiaj bezpiecznik decydując się na rekomendację danego rozwiązania bierze to pod uwagę?

Będąc administratorem, a później architektem w jednym z największych portali w Polsce (łezka się kręci, co my wyrabialiśmy w pracy i po...:-)) przy wyborze danego rozwiązania najważniejsze dla mnie były takie cechy jak:
- Wydajność -> Skalowalność
- Dostępność (w rozumieniu zapewnienia HA)
- Bezpieczeństwo (! - nigdy nie przestałem być bezpiecznikiem)
- inne jak łatwość w utrzymaniu, wsparcie zew./wew., elastyczność jeśli chciałbym coś zmienić, dostępność dokumentacji/kodu źródłowego (!), realne przełożenie na polepszenie się jakości usług w stosunku do wymaganej pracy przy wdrożeniu/utrzymaniu i rozwoju (!!!) oraz kilka innych

Dzisiaj (wczoraj też ;)) bezpiecznik musi patrzeć przez pryzmat właśnie takiego administratora.

Przypadek #1 i ostatni: ProPolice
Dodatek ProPolice, teraz natywny w nowych gcc, to pewien narzut na aplikację, która została skompilowana z odpowiednimi opcjami (-fstack-protector, -fstack-protector-all). Czy martwię się nim? Googlając po benchmarkach dostępnych w sieci nie specjalnie. Moja propozycja prawdopodobnie będzie trafiona i nie spowoduje problemów z wydajnością. Ba. Część dystrybucji przygotowuje paczki specjalnie z ProPolice i innymi flagami dla aplikacji w C (Ubuntu? Gentoo? RHEL? CentOS? ... ?). Świat od razu wydaje się być bezpieczniejszy. Mark Cox nie tak dawno temu napisał ciekawe podsumowanie o RHEL 4 i wpływie hardeningu by default na ryzyko wykorzystania podatności jakie zostały odkryte przez ostatnie 4 lata. Czy na pewno jest tak fajnie? Właściwie co zyskał bezpiecznik rekomendując i wymagając stosowanie ProPolice, a co administrator? Wezmę pod uwagę jeszcze developera.

Bezpiecznik: "Teraz exploity mi nie straszne!" - oj myli się ;-)
Administrator: "O ja &*$#)%(^%&, na tym starym systemie nie ma wsparcia dla ProPolice. Mam tu zrobić upgarde gcc? No way!", "Jasne, będę musiał Makefile przeglądać zanim coś skompiluję, &^*)($#^$ bezpiecznik!" - częściowo ma racje ;]
Developer: "ProPo..., że co? A po co mi to?" - Bezpiecznik mówiący developerowi, że przez to trudniej będzie wykorzystać jego błędy raczej nie zdobędzie jego symaptii ;-)

Pomijając zbędną złośliwość każdego z bohaterów widać, że wprowadzenie rekomendacji może implikować trochę dodatkowych prac i spowodować czasowy spadek wydajności... efektywności pracy wielu ludzi. Stanie się tak pod warunkiem, że rekomendacja będzie praktykowana.

Ktoś czytając ten wpis może pomyśleć, że trafiłem w swoim życia na "złych" ludzi. Leniwych adminów i programistów. To nie tak. Wiem, że nie każda rekomendacja spotka się z zachwytem, szampanem i imprezą do białego rana. Wiem, że administrator/programista (nie wrzucam Was do jednego worka!) skupiony jest na czymś innym niż bezpieczeństwo. Nie o to pyta go szef każdego ranka. Chcę pokazać, że rekomendacja stosowania dwóch opcji do gcc niesie za sobą konsekwencje, a znam przykłady, które wymagają nieporównywalnie większego nakładu pracy po stronie samego IT by rekomendacja weszła w życie. Mam wrażenie, że dlatego tak dużo kupuje się - kupują ci, których stać - pudełek z kolorowym GUI, które konfiguruje się w "kwadrans", a właściwie jego możliwości kończą się tip-top dalej niż zaczynają. Trochę generalizuję i nie nawołuję do bojkotu rozwiązań "z pudełka" - czasami są bardzo przydatne i wygodne, chciałbym jednak by IT lepiej rozumiało potrzeby Security i na odwrót.

Idealną sytuacją jest kiedy osoby reprezentujące IT i Security dzielą się uwagami, spostrzeżeniami i sugestiami odnośnie rekomendacji. Jeśli rozmowa jest konstruktywna i merytoryczna to jest szansa osiągnąć dobry wynik rozmów, satysfakcjonujący obie strony.

PS
Rekomendacja ProPolice jest słuszna w pewnych warunkach i ten wpis nie ma za zadanie odwrócić bezpieczeników od stosowania jej.

PS#2
Rekomendacje skonsultowane z IT będą lepiej przyjmowane, a co najważniejsze, skuteczniej wdrażane.