Open source i bezpieczeństwo

Przeczytaj także: Linux w polskich przedsiębiorstwach

Masa krytyczna w świecie „open source” pochodzi od dziesiątek, setek lub nawet tysięcy, którzy analizują i testują istniejące oprogramowanie oraz składają nowy kod. Ci programiści dostarczają duże ilości inspiracji, innowacji i po prostu ciężką pracę, co jest nie do powielenia w środowisku komercyjnym. Jednak główny zespół koordynuje pracę mas i wybiera najlepsze dokonania, żeby włączyć je do podstawowej gałęzi oprogramowania.

Świetnym przykładem najnowszej próby wprowadzenia oprogramowania „open source” jest projekt netfilter (), pakiet filtrów oparty na Linuksie, który cechuje „firewalling” (zabezpieczanie przed włamaniami w sieci), translacja adresów sieciowych (Network Address Translation - NAT), równoważenie obciążenia i inne pakiety zniekształcające. Projekt powstał w 1999 roku w Australii i urósł do więcej niż 100 tys. linijek kodu pisanych przez 700 programistów. Obecnie jest 300 aktywnych programistów piszących około 1400 postów miesięcznie na rozwojowe listy mailingowe. Główny zespół składa się z czterech osób, które dokonują selekcji aplikacji i wybierają średnio 65 poprawek i napraw kodów na miesiąc.

Ograniczenia „open source”

Projekty „open source” są znakomitym źródłem światowej klasy technologii bezpieczeństwa, ale nie są panaceum dla programistów lub menagerów IT, którzy potrzebują wprowadzać solidne, wykonalne oprogramowanie do prawdziwego środowiska produkcji. Społeczność „open source” jest napędzana przez techniczny entuzjazm, a nie potrzeby komercyjne. Chociaż większość programistów „open source” bardzo dobrze rozumie potrzeby działów IT, nie można się spodziewać, że będą poświęcać swój wolny czas pracując nad przyziemnymi sprawami zarządzania. W efekcie projekty „open source” dostarczają olśniewających, innowacyjnych rozwiązań podstawowych problemów, ale łatwość użycia i łatwość zarządzania wymagają od użytkowników systemów Unixowych większego wysiłku poznawczego..

Ta tendencja może być manifestowana na wiele sposobów: wszystkie zadania można wykonać z poziomu linii poleceń, mniej intuicyjne są również interfejsy graficzne oraz ręczne metody uaktualniania oprogramowania. Są to drobne mankamenty dla świetnie wykwalifikowanych
programistów, którzy uwielbiają zgłębianie nowych elementów technologii, ale nie sprawdzają się jako administratorzy systemów czy managerowie, którzy muszà ukończyć szereg zadań w krótkim czasie.

Poza poziomem pojedynczego projektu „open source” nie ma zachęty do łączenia oddzielnych pakietów w to, co manager IT widziałby jako kompletne rozwiązanie. Chociaż cały kod „open source” jest dostępny do przeglądu, to nie znaczy, że cały jest przeglądany równie gruntownie. Wielu obejrzy technicznie pasjonujące części, ale środowisko nie nadaje się do powiedzenia: Czy mógłbyś przejrzeć i przetestować nudne części? Na koniec, opcje wparcia są ograniczone dla większości oprogramowania „open source”.

Wykorzystanie oprogramowania „open source” do celów bezpieczeństwa

Jak organizacje mogą wykorzystać gwałtowny wzrost i innowacyjność społeczności „open source” ( i jej niskie koszty) bez doświadczania ograniczeń? Są zasadniczo dwie możliwości: Przydzielić wystarczające środki, żeby wypełnić luki; Pozwolić sprzedawcy połączyć i wspierać rozwiązanie oparte na komponentach „open source”.

W obu przypadkach zadania są zasadniczo takie same: Ktoś chce stworzyć interfejsy i dokumentację, żeby uczynić technologię łatwo dostępną dla typowego, przepracowanego użytkownika lub administratora (którego rozprasza stale ogromna liczba rywalizujących wymagań); Ktoś chce utworzyć zautomatyzowane procesy potwierdzania ustawień, łat programowych, uaktualniania oznaczeń zagrożeń systemu i robienia zapasowych kopii konfiguracji; Ktoś chce stworzyć raporty, aby przeciętny administrator (który jest wciąż roztargniony i udręczony) mógł identyfikować i rozwiązywać problemy oraz śledzić trendy; I jeśli rozwiązanie zawiera wielorakie składniki ( co jest typowe w bezpieczeństwie), ktoś chce zintegrować składniki i poddać gruntownym testom, żeby się upewnić, że elementy pracują razem we wszystkich typach niesprzyjających warunków.