Oddzielne programowanie i produkcja

Zwykłą praktyką jest nadanie programistom lokalnych praw administratora / użytkownika root na ich stacji roboczej. Jednak programiści powinni mieć dostęp tylko do środowisk programistycznych i nigdy nie mieć dostępu do danych na żywo. Administratorzy systemów - którzy mają dostęp do produkcji - powinni mieć znacznie bardziej kontrolowane stacje robocze. Idealnie byłoby, gdyby stacje robocze sys-admin nie miały dostępu do Internetu, chociaż jest to rzadkie w praktyce.

Odmiana, którą widziałem, polega na tym, że programiści mają zablokowaną korporacyjną kompilację, ale mogą robić, co chcą, w ramach wirtualnego maszyn. Może to jednak być denerwujące dla programistów, ponieważ maszyny wirtualne mają zmniejszoną wydajność, a korzyści w zakresie bezpieczeństwa nie są tak duże. Dlatego częściej zdarza się, że programiści mają po prostu pełny dostęp do własnej stacji roboczej.

A więc ta odpowiedź pochodzi z punktu widzenia programisty. Miej to w pamięci.

Po pierwsze, brak praw „lokalnego administratora” na moim komputerze to znak, że powinienem poszukać pracy gdzie indziej. Prawie niemożliwe jest pisanie kodu, majstrowanie przy różnych rzeczach i utrzymywanie łańcucha narzędzi, jeśli musisz pytać o pozwolenie za każdym razem, gdy musisz zaktualizować (lub przetestować) nową zależność lub narzędzie. Oto poziomy uprawnień, których wymagam . Pamiętaj, że zazwyczaj jestem dość wysoko na drabinie, że tak powiem.

• Całkowite i pełne zarządzanie moim lokalnym komputerem
• Całkowite i pełne zarządzanie całym sprzętem programistycznym i testującym
• Pewien poziom dostępu administratora do produkcji serwery (to staje się trudne, nie potrzebuję ani nie chcę wszystkiego, ale potrzebuję wystarczająco dużo, aby zdiagnozować i naprawić problemy, które występują na produkcji, i wystarczająco dużo, aby faktycznie wdrożyć kod (zakładając, że to ja muszę nadzorować wdrażanie kodu). Zwykle ten poziom dostępu ewoluuje w czasie, ale zaczyna się od plików dziennika.

Mniej i możesz znaleźć nowego programistę.

To powiedziawszy, z tym poziomem dostępu wiąże się duże ryzyko. Dlatego zwykle zalecam utworzenie oddzielnej sieci. Umieść wszystkie „rzeczy” związane z programistami we własnej sieci. Jego własne AD, własny hosting plików, własne wszystko i nigdy nie pozwól komunikuje się z siecią produkcyjną. (ale niech wychodzi do internetu).

Tak, oznacza to zduplikowany sprzęt (lub VPS), ale i tak jest to potrzebne do testów. Tak, to oznacza trochę więcej ead podczas aktualizacji lub administrowania, ale znowu jest potrzebny do testowania. Potrzebujesz również miejsca, w którym zobaczysz „Co stanie się z oprogramowaniem X, jeśli zaktualizuję serwer AD?” Spójrz, masz całą sieć maszyn testowych gotowych do tego rodzaju testów.

Z powodzeniem wdrożyłem (z pomocą dobrego zespołu IT) oddzielną sieć VLAN dla wszystkich "rzeczy" deweloperskich i jeden host VPS, do którego programista ma pełny dostęp i może robić wszystko, czego chce. Na tym hoście znajduje się serwer AD skonfigurowany przez dział IT w taki sposób, aby wyglądał jak mniejsza wersja serwera AD firmy. Następnie zestaw dokumentów i wskazówek, co na przykład powinien działać serwer WWW. Co powinien działać serwer DNS, co serwer xyz powinien działać. Następnie częścią „rozwoju” jest zainstalowanie i skonfigurowanie tych serwerów VPS do naszego użytku. Wszystko w tej sieci VLAN jest całkowicie odizolowane od produkcji i traktowane jako zewnętrzne w stosunku do firmy. W końcu dla zasobów, do których potrzebowaliśmy dostępu (takich jak e-mail), tworzony jest zestaw „przebić”. Zwykle traktowano to tak, jakbyśmy byli zewnętrzni, a lista tych narzędzi była bardzo mała.

Z punktu widzenia programisty:

Twoim zadaniem jest zapobieganie zmianom (znane błędy i luki są lepsze niż nieznane, prawda?), ale ja mam zmienić rzeczy. To stawia nas w impasie. Moja praca polega na tworzeniu / zmienianiu rzeczy. Jeśli Twoja polityka to uniemożliwia, to, podobnie jak w przypadku każdej innej przeszkody, częścią mojej pracy jest znalezienie sposobu na obejście tego.

Co Twoim zdaniem jest bardziej niebezpieczne, programista, któremu przyznałeś dostęp do rzeczy, których potrzebuje do wykonywania swojej pracy lub kogoś, kto uzyskał ten dostęp, ucząc się, jak obejść wszystkie twoje środki obronne? I dlaczego Twoja firma płaci Tobie i Twoim programistom za prowadzenie tej wojny przeciwko sobie, podczas gdy powinniście współpracować?

Prosta odpowiedź brzmi: daj programistom dostęp do tego, czego potrzebują do wykonywania swojej pracy. I porozmawiaj z nimi. Mogą wystąpić rzadkie sytuacje (inżynieria wsteczna w pomieszczeniu czystym z poważnymi konsekwencjami prawnymi lub przetwarzanie ściśle tajnych danych rządowych), w których potrzebna jest bardziej skomplikowana polityka. Ale w większości nie jest to taka wielka sprawa. Jeśli rozpoczniesz wojnę i sprawisz, że twoi deweloperzy staną się wrogami, albo odejdą, albo staną się znacznie bardziej niebezpieczni, niż gdybyś z nimi pracował.

Rozsądne środki obejmują zakaz zezwalania na zrzuty produkcyjnej bazy danych na laptopach programistów (tylko testowanie baz danych fałszywe dane). W ten sposób, jeśli laptop zostanie skradziony, żadne poufne dane nie zostaną utracone. Ale jeśli deweloper musi coś debugować, nadal potrzebuje dostępu do kopii produkcyjnej bazy danych gdzieś w kontrolowanym środowisku.

Ograniczanie dostępu do Internetu jest śmieszne. Równie dobrze możesz wymagać, aby wszyscy twoi programiści napisali swój kod na papierze za pomocą pióra i atramentu.

Porozmawiaj z programistami, znajdź sposób, aby dać im to, czego potrzebują do wykonywania swojej pracy, zachowując jednocześnie bezpieczeństwo potrzebne do zabezpieczenia ważnych danych. Szczegóły będą zależały od Twojej firmy i danych, z którymi masz do czynienia. Ale prawdopodobnie nie będzie to wymagało drakońskich środków.

Inżynier ds. bezpieczeństwa nie zajmuje się komputerami, tym zajmuje się dział obsługi. W twoim przypadku będziesz wymagać od niego zainstalowania trzech narzędzi:

• hiperwizora
• docker
• oprogramowanie bazy danych

Stamtąd może dodawać i usuwać maszyny do rozwoju tak często, jak chce (nie powinien wymagać interwencji inżyniera sekund). W odniesieniu do twojego „nieuczciwego kontenera”. Ogólnie rzecz biorąc, nie wdrażasz kontenerów na innym serwerze, wdrażasz pliki docker, które pobierają kod z repozytorium kodu lub pobierasz podpisany plik binarny skompilowanego kodu (co jest jeszcze bezpieczniejsze).

Jeśli chodzi o oszustów, mogę sobie tylko wyobrazić, że osoba atakująca uzyska dostęp i doda więcej kodu. Dlatego na każdym etapie SDLC należy mieć wbudowane zabezpieczenia, aby zapewnić, że cały kod zostanie przynajmniej przejrzany lub przeszedł przez innego programistę przed przeniesieniem go w górę drzewa. Ponadto można również zintegrować skanery kodu, aby automatycznie skanować w poszukiwaniu podejrzanych lub podatnych na ataki fragmentów kodu.

Trzeci punkt tak naprawdę zależy. Firmy takie jak Riot Games właśnie to robią. Odkryli, że ograniczanie inteligentnych osób doprowadzi je do obchodzenia kontroli. Postanowili więc zastosować proste zasady i efektywne szkolenie uświadamiające, aby mieć pewność, że nie zapominają o bezpieczeństwie i dają pełne uprawnienia administracyjne. Rozdali małe karteczki, na których napisali, czym powinni się zająć i na co powinni uważać.

Dajemy naszym programistom dostęp administracyjny do ich komputerów i informujemy ich o zasadach. Większość z nich korzysta z Linuksa, ale mamy też kilku programistów w systemie Windows. Wszyscy wiedzą, że mogą przechowywać swoje dokumenty, projekty itp. W naszych współdzielonych plikach (które mają bardziej szczegółowe uprawnienia) i przesyłać swój kod źródłowy na nasz serwer Git.

Wiedzą również, że nie spędzę dużo czasu aby rozwiązać problem z ich systemem operacyjnym. Jeśli ich komputer nie działa, często po prostu go wyczyścimy i ponownie zainstalujemy system operacyjny. Typowe aplikacje i ustawienia są automatycznie instalowane przez Puppet, a resztę będą musiały wykonać samodzielnie. Większość z nich ma repozytorium Git z plikami dotfiles (ustawieniami i preferencjami środowiska).

Czas, który tracą w takim przypadku, jest wystarczającą motywacją dla większości z nich. Lubią pracować, zamiast bawić się naprawami systemu operacyjnego. Jeśli stracą ważną pracę, ponieważ była przechowywana tylko lokalnie, będą niezadowoleni ze strony współpracowników i szefa.

Nie blokujemy żadnej witryny internetowej ani aplikacji (z wyjątkiem opartego na DNS filtra anty-malware ), ale mają pewne zasady firmy dotyczące takich rzeczy, jak nielegalne oprogramowanie. W większości rzeczy polegamy na presji rówieśników. Ludzie, którzy spędzają czas na Facebooku, nie są produktywni i nie trwają długo. Wiele naszych zasad opiera się na systemie honorowym i wydaje się, że działa on dobrze.

To zasadniczo zależy od kontekstu. Rozważ następujące dwie konfiguracje, z którymi obie spotkałem na wolności:

• Deweloperzy pracują na maszynach, których są właścicielami lub do których mają pełny dostęp, łącznie z instalacją własnych systemów operacyjnych. Nie ma ograniczeń co do tego, jak piszą aplikację. Mają dostęp SSH do systemów produkcyjnych za każdym razem, gdy są podłączeni do sieci, w tym VPN.
• Cały rozwój odbywa się w laboratorium programistycznym z izolacją powietrzną, do którego programiści nie mogą wprowadzać urządzeń elektronicznych. Na wszystkich komputerach jest wstępnie zainstalowane całe dozwolone oprogramowanie. Artefakty, które można wdrożyć, są bezpiecznie dostarczane na nośnikach fizycznych do innego zespołu, który jest odpowiedzialny za wdrożenie.

Obie te konfiguracje były odpowiednie w kontekście - biorąc pod uwagę zagrożenia, z jakimi borykała się organizacja, oraz potrzeby projektu.

Jest tutaj podstawowy kompromis. Każde odejście od pierwszej możliwości w kierunku drugiej zmniejsza produktywność. Każdy, kto ma jakąkolwiek kontrolę nad aplikacją, jest na zaufanej pozycji. Wszystko, czego nie możesz im zaufać, jest czymś, bez czego będziesz musiał się obejść lub stworzyć proces przekazania, który zrobi ktoś inny. Nie możesz odebrać zaufania bez zmniejszenia produktywności.

To zależy od rodzaju oprogramowania, które tworzysz i wielkości Twojej organizacji.

W przypadku pojedynczej stacji roboczej programisty rockstar w małej firmie użyłbym wyjątku bezpieczeństwa na poziomie kierowniczym. Ryzyko (w tym irytacja IT, kadry kierowniczej i innych programistów) należałoby omówić, ale ostatecznie, jeśli gwiazda rocka nie postawi na swoim, prawdopodobnie przeniesie się do innej firmy. Ci faceci nie tolerują tarcia, jeśli je napotkają, mogą łatwo znaleźć ciekawsze miejsca do pracy.

Bardziej typowym scenariuszem niż stacja robocza typu uber jest posiadanie klastra programistycznego, w którym operacje zarządzają życiem i śmierć maszyn wirtualnych, środowisko jest monitorowane za pomocą IDS / IPS, a dostęp do Internetu (w klastrze deweloperskim) jest ograniczony, ale otwierany w razie potrzeby. np. w przypadku dokumentacji ... nie ma nic złego w umieszczaniu na białej liście wszystkich źródeł technologii związanych z twoimi pracami rozwojowymi. Programiści i tak nie mogą pobierać kodu chcąc nie chcąc. Muszą udokumentować swoje źródła i zweryfikować dziwne licencje.

Jeśli uda ci się zdobyć ucho rockstara, może on pomóc w przekazaniu wymagań operatorom i kierownictwu oraz zaprojektowaniu klastra i procesów oraz przeszkolić zespoły programistyczne na potrzeby.

Jeśli jest budżet, a programista jest niechętny ... to IMHO, nie masz do czynienia z gwiazdą rocka, ale diva i ich marudzenie powinny być przenoszone na ryzyko menedżerskie podpisania.

Najtrudniejszą częścią jest zarządzanie żywotnością maszyn i upewnianie się, że spostrzeżenia deweloperów nie stają się "operacyjnymi" systemami produkcyjno-programistycznymi. Ale to znacznie łatwiejsze niż maszyny wirtualne na stacjach roboczych programistów.

To pytanie rodzi wiele interesujących pytań i wyzwań. Każdy, kto przez wiele lat pracował jako programista, a następnie zajął się bezpieczeństwem, potrafię docenić wiele argumentów i punktów widzenia wyrażonych w odpowiedziach i komentarzach. Niestety nie ma ostatecznej odpowiedzi, ponieważ prawidłowe rozwiązanie zależy od kontekstu, ekspozycji na ryzyko i apetytu organizacji na ryzyko.

Bezpieczeństwo nie jest czymś, co można zmierzyć absolutnie. Za każdym razem, gdy natkniesz się na osobę odpowiedzialną za bezpieczeństwo, która stale mówi absolutnie i nalega na egzekwowanie określonej polityki, niezależnie od wszystkiego innego, jest albo niedoświadczona, albo niekompetentna. Rolą inżyniera bezpieczeństwa jest ułatwienie procesów biznesowych, a nie ich utrudnianie oraz zapewnienie podejmowania decyzji biznesowych, które są informowane o odpowiednich zagrożeniach bezpieczeństwa. Dobry inżynier bezpieczeństwa będzie wiedział, że każda polityka, która uniemożliwia pracownikom wykonywanie ich pracy, nieuchronnie zawiedzie, ponieważ personel znajdzie sposób na obejście tej polityki. Częściej niż nie, prace wokół będą jeszcze mniej bezpieczne. Obowiązkiem osoby odpowiedzialnej za bezpieczeństwo jest zrozumienie różnych ról w organizacji i upewnienie się, że zasady są tak skonstruowane, że nie tylko wspierają to, czego wymaga rola, ale zachęcają do dobrych praktyk i zniechęcają do złych. Może to być trudne, szczególnie w dużych organizacjach. Jednocześnie programiści i inne osoby w organizacji również muszą zdawać sobie sprawę, że mogą nie mieć wszystkich istotnych informacji, aby zrozumieć, dlaczego wymagane są określone zasady. Zbyt często programiści i inni postrzegają inżyniera bezpieczeństwa jako przeszkodę lub przeszkadzającego biurokratę, który nie rozumie, czego potrzebuje, aby wykonać swoją pracę.

Najczęściej sposobem rozwiązania tych problemów jest komunikacja. Często zdarzało mi się, że programiści przychodzili do mnie sfrustrowani, ponieważ niektóre zasady, które uważają za bezcelowe, wchodzą im w drogę. Kiedy usiądziemy i omówimy problem, zwykle zdarza się kilka rzeczy;

• Programista albo błędnie zinterpretował zasady, albo przeczytał w niej założenia, które są niepoprawne i wydaje się, że polityka zapobiega czemuś, czego nie robi. Często prowadzi to do przeglądu polityki w celu poprawy przejrzystości.
• Inżynier ds. Bezpieczeństwa zdaje sobie sprawę z uzasadnionego wymogu biznesowego, który należy spełnić w sposób zapewniający odpowiednią kontrolę bezpieczeństwa. Prawdopodobnie spowoduje to przegląd polityki.
• Deweloper jest świadomy innych wymagań lub zagrożeń, które początkowo nie były dla niego oczywiste. Powoduje to często, że deweloper identyfikuje alternatywne rozwiązania spełniające jego wymagania.
• Zidentyfikowano problem, którego nie można rozwiązać w sposób zadowalający którąkolwiek ze stron w sposób mieszczący się w akceptowanym przez organizację apetycie na ryzyko (tj. Przy akceptowanym poziomie ryzyka ). Taka sytuacja zwykle skutkuje eskalacją problemu na szczeblu wykonawczym w celu podjęcia decyzji. Trudność w wykonaniu tego będzie zależała od wielkości i struktury organizacji. Po podjęciu decyzji zarówno programista, jak i inżynier ds. Bezpieczeństwa muszą pracować zgodnie z parametrami określonymi przez kierownika, aby znaleźć możliwie najlepsze rozwiązanie.

Pojawiło się wiele krytycznych odpowiedzi polityk, które mają negatywny wpływ na ich poziom produktywności. Chociaż każdy deweloper powinien zgłosić takie obawy, ostatecznie musi albo zaakceptować decyzję, którą podejmie kierownik, albo poszukać alternatywnego pracodawcy. Zakładanie, że wiesz lepiej lub że masz specjalne prawo do ignorowania tej polityki, jest aroganckie i niebezpieczne zarówno dla Ciebie, jak i dla Twojego pracodawcy. Jeśli jesteś przekonany, że masz rację, powinieneś być w stanie przekonać kierownictwo. Jeśli nie możesz, albo nie jesteś tak dobry, jak myślisz, brakuje odpowiednich umiejętności komunikacyjnych, aby przedstawić przekonujące argumenty, nie posiadasz wszystkich informacji lub pracujesz dla niekompetentny pracodawca. Po 35 latach w branży i pomimo tego, co Dilbert może skłonić cię do myślenia, to drugie nie jest tak powszechne, jak można się spodziewać. Najczęstszym źródłem konfliktów w tym obszarze jest słaba komunikacja i brak informacji.

Częstym błędem wśród programistów (i moim winnym) jest skupienie się tak bardzo na swoim konkretnym zadaniu lub celu, że Tęsknisz za szerszym obrazem, którym liderzy zespołów, menedżerowie i dyrektorzy muszą również zarządzać. Środowiska, w których programiści otrzymali dużą swobodę i zaufanie, co zaowocowało wysokim poziomem produktywności, ale skutkowało to innymi problemami - sytuacją, w której akey deweloper odszedł lub jest nieobecny przez dłuższy czas i nikt inny nie może odebrać działa, ponieważ wszystko jest na ich unikalnie skonfigurowanym i zarządzanym pulpicie lub próbuje debugować trudny problem, którego nie można łatwo odtworzyć z powodu braku standardowych ustawień / konfiguracji lub radzenia sobie z możliwym naruszeniem bezpieczeństwa z powodu przypadkowego pozostawienia przez programistę części usługowej, która była w fazie rozwoju brakowało standardowych kontroli bezpieczeństwa. Bycie programistą skoncentrowanym na określonej dziedzinie lub technologii nie gwarantuje również wiedzy we wszystkim innym. Niektórzy z najlepszych programistów, z którymi kiedykolwiek pracowałem, byli jednymi z najgorszych, jeśli chodzi o bezpieczeństwo i / lub zarządzanie środowiskiem. Jest to prawdopodobnie częściowo spowodowane skupieniem się na konkretnym problemie, a bardziej prawdopodobnie po prostu wydajnością. Żaden z nas nie jest w stanie pokonać wszystkiego i musimy zdawać sobie sprawę, że czasami ważne jest, aby zwrócić się do tych, którzy specjalizują się w dziedzinach, w których nie mamy.

Zmieniające się środowisko

Jednym z głównych powodów wprowadzenia zasad ograniczających to, co można zrobić na pulpicie, jest założenie, że komputery stacjonarne w sieci lokalnej mają wyższy poziom zaufania niż komputery stacjonarne poza siecią. Tradycyjnie znajdują się wewnątrz zapory i na innym obwodzie obrony i mieć ruchomy dostęp do zasobów informacyjnych. Oznacza to, że stwarzają większe ryzyko i dlatego potrzebują większej kontroli bezpieczeństwa. Inne przyczyny restrykcyjnych zasad / praktyk obejmują standaryzację środowisk, która może obniżyć koszty wsparcia i zwiększyć spójność (co było szczególnie prawdziwe, gdy było więcej aplikacji zależnych od platformy / systemu operacyjnego - pamiętajcie o wszystkich tych okropnych aplikacjach, które wymagały AtiveX lub określonej wersji IIE).

Rozwój maszyn wirtualnych i kontenerów, usług w chmurze i towarowych usług IT oraz zwiększona przepustowość sieci skutkuje szeregiem zmian, które prawdopodobnie sprawią, że wiele problemów poruszonych w tym wątku stanie się nieistotnych. W szczególności przejście w kierunku sieci o zerowym zaufaniu spowoduje prawdopodobnie znaczące zmiany. W sieci o zerowym zaufaniu, urządzenia wewnątrz sieci nie wykazują żadnego specjalnego dodatkowego poziomu zaufania w porównaniu z urządzeniami poza siecią. Nie masz możliwości dostępu do zasobów tylko dlatego, że masz właściwy adres IP. Zamiast tego zaufanie opiera się bardziej na połączeniu informacji o użytkowniku i urządzeniu. Zasady określające, do czego możesz uzyskać dostęp, są określane przez Twoje poświadczenia i urządzenie, z którego się łączysz. Miejsce, w którym znajduje się to urządzenie, nie ma znaczenia. Jest to również model, który znacznie lepiej pasuje do wzrostu BYOD i zwiększonej mobilności siły roboczej oraz rosnących wymagań dotyczących zatrudniania pracowników w oparciu o progi / umiejętności i lokalizację geograficzną.

Gdy usuniesz poziom „zaufania” związane z urządzeniem, nie potrzebujesz kontroli nad tym, co możesz zastosować do urządzenia. Nadal możesz wymagać urządzeń do obsługi określonych profili - na przykład możesz odmówić komukolwiek dostępu do swoich zasobów, jeśli na ich urządzeniu działa system Windows XP itp. Jednak mniej martwisz się o urządzenie. Podobnie nie będziesz wykonywać tylu zadań bezpośrednio na urządzeniu. W pewnym stopniu urządzenie będzie bardziej jak cienki klient. Będziesz używać maszyn wirtualnych i kontenerów hostowanych zdalnie. To samo w sobie nie rozwiąże wszystkich problemów i może być postrzegane jako zwykłe przeniesienie niektórych z nich z lokalnego pulpitu do zdalnej maszyny wirtualnej lub kontenera. Jednak po połączeniu tego z różnymi orkiestracjami w stylu DevOps, wiele powodów, dla których programiści mogą potrzebować rozszerzonych uprawnień, zostaje usuniętych. Na przykład nie możesz wymagać dostępu do systemów produkcyjnych. Promocja nowego kodu będzie przeprowadzana za pośrednictwem zorganizowanego systemu ciągłej integracji, a gdy będziesz musiał debugować problem, otrzymasz maszynę wirtualną lub kontener, który jest dokładnym klonem systemu produkcyjnego.

Żadna z tych zmian nie będzie magicznie rozwiązują wszystko, ale zapewnią szerszą gamę bardziej elastycznych narzędzi i rozwiązań o potencjalnie mniejszym stopniu złożoności. Zmniejszenie złożoności sprawi, że zarządzanie bezpieczeństwem będzie trudniejsze. Łatwiejsze zarządzanie bezpieczeństwem doprowadzi do mniej niezamierzonych lub niepotrzebnych ograniczeń lub utrudnień w wykonywaniu obowiązków służbowych. Jednak pod koniec dnia kluczowe wymagania to

• Uznanie przez wszystkich, że jeden rozmiar nie pasuje do wszystkich. Wszystko musi zostać ocenione w kontekście organizacji.
• Gotowość do stawiania potrzeb organizacji na pierwszym miejscu.
• Dobra komunikacja dwukierunkowa.
• Gotowość wszystkich stron do wypracowania rozwiązań, które są wzajemnie akceptowane oraz
• Gotowość wszystkich stron do kompromisu
• Chęć do pracy w systemie i dostosowywania przepływu pracy lub preferowanego sposobu robienia rzeczy do wymagań organizacji

Jestem również programistą i oto moja opinia:

Problem jest gorszy niż myślisz

Nie ma łyżki

Rozwój nie polega na oprogramowanie. Rozwój polega na tworzeniu lub ulepszaniu produktów, usług i procesów. Oprogramowanie jest ważnym narzędziem, ale nie jedynym. Dobrzy programiści zdefiniują procesy w szerszym sensie, aby wiedzieć, które komponenty oprogramowania stworzyć, a także zaproponować ludzki, logistyczny proces zarządzania ryzykiem. Nie ma sensu opracowywanie systemu oprogramowania zależnego od procesów ludzkich, logistycznych i papierowych, które nie są wdrażane.

Nie ma żadnych zasad tworzenia oprogramowania, ponieważ program definiuje zasady. To właśnie sprawia, że ​​programowanie jest najgorszym środowiskiem do zabezpieczenia.

Ale to nie znaczy, że nie należy wprowadzać pewnych kontroli. Wręcz przeciwnie, wiele mechanizmów kontrolnych powinno być skonfigurowanych przez sam zespół programistów.

Proces inżynieryjny

Istnieją firmy, które opowiadają się za oddzieleniem biznesu od technologii w procesie odgórnym. Jest to rzeczywiście bardzo popularne, ponieważ sugeruje, że ludzie biznesu bez wiedzy technicznej powinni być na szczycie. Leniwi ludzie to uwielbiają . Ale w inżynierii projekt odgórny po prostu nie działa. Feyman (1985) napisał o tym fajny artykuł w prezydenckiej komisji, która przeanalizowała eksplozję Challengera. Zasadniczo inżynieria odgórnych procesów ostatecznie psuje firmę. Moje doświadczenie rynkowe wzmacnia to zrozumienie.

Eksplozja Challengera jest doskonałym przykładem. Menedżerowie NASA zeznają przed kamerą w komisji śledczej, że opracowali gumę, która może pozostać elastyczna poniżej 60 stopni poniżej zera. Stało się to sprzeczne z prostym fizycznym eksperymentem przeprowadzonym w liceum przez jednego z komisarzy (wkład gumowy do lodowatej wody dociśniętej klamrą). To był świetny przykład, ponieważ ten element gumowy musiał być elastyczny, aby wzmacniacz nie eksplodował; ponieważ do tego potrzebne były letnie temperatury, wzmacniacz działał tylko latem. Charakterystyka pojedynczego komponentu definiuje widoczną cechę całego produktu, która jest bardzo ograniczająca.

Inżynieria powinna odbywać się oddolnie, ponieważ musisz znać ograniczenia i słabości każdego komponentu, aby opracować procesy w celu ich złagodzenia . Najczęściej procesy łagodzenia skutków nie są oprogramowaniem i mają wpływ na koszt produktu. Oznacza to, że cechy i ograniczenia poszczególnych komponentów będą określać cechy produktów, usług i procesów.

Procesy odgórne są zasadniczo zepsute. Wiele firm, które przejmują tę filozofię na papierze, nadal odnosi sukcesy rynkowe. Ale kiedy zejdziesz na dół i zbadasz ich duże i najbardziej udane projekty, dowiesz się, że były prowadzone poza normalnymi zasadami firmy. Największe sukcesy osiąga się, gdy jedna osoba, która ma głęboką wiedzę inżynierską i wizję rynkową, ma nieformalne uprawnienia. Ponieważ dzieje się to nieformalnie, kierownictwo uważa, że ​​proces odgórny działa. Zaznaczają, że wszystkie inne zespoły są niekompetentne. Przymykając oczy na fakt, że początkowy zarys projektu po opuszczeniu „fazy szczytowej” został całkowicie zignorowany i nie opisuje zbudowanych produktów, usług i procesów.

Twój menedżer może zdefiniować, że do końca miesiąca skonstruujesz urządzenie teleportacyjne, ponieważ doszedł do wniosku, że pozwoli to na wysoki zysk w branży turystycznej ... ale to nie sprawi, że tak się stanie. Takie są projekty odgórne, stawiaj oczekiwania, które nie są technicznie uzasadnione.

Nie zrozum mnie źle, dobrze jest widzieć problem z wielu perspektyw. Analiza oddolna, odgórna, SWOT i inne są dobre dla analizy, ale prawdziwy wysiłek inżynieryjny jest oddolny. Nie ma prawdziwego celu bez wykonalności technicznej.

Bezpieczeństwo rozwoju

Musimy pamiętać, że programiści będą regularnie zmieniać oprogramowanie firmy, dzięki czemu mogą: zmieniać to, co pojawia się na ekranie każdego, wysyłać automatyczne e-maile do każdego, w tym do siebie samego, lub otwierać tylne drzwi, aby robić, co chcą. Oznacza to, że przestępca zatrudniony jako programista może wyrządzić firmie znaczne szkody.

Co gorsza, jest wiele firm, które nie egzekwują proweniencji repozytorium kodu źródłowego, a następnie wynajęty programista może dostarczyć plik binarny inny niż podane źródło. Pozwala to przestępczym programistom na przejęcie firmowych systemów, jeśli nie zostaną zatrudnieni, wszystko wkrótce przestanie działać.

Dla mnie bezpieczeństwo programowania powinno skupiać się na:

• Kontrola wersji kodu źródłowego : zapewnienie, że kod źródłowy i potrzebne komponenty trzeciej części są przechowywane w bezpiecznym miejscu.
• Strategiczny podział pracy : młodszy i tymczasowy programiści muszą mieć ograniczony dostęp do kodu źródłowego i danych. Potrzebują jedynie dostępu do komponentów, które zmieniają, aby młodszy programista nie był w stanie zrozumieć wewnętrznego działania wszystkich systemów i móc to wykorzystać.
• Zaufaj głównym programistom : programiści senior / Core będą musieli wiedzieć wszystko, mieć do wszystkiego dostęp, planować i rozprowadzać zadania oraz diagnozować poważne problemy. Ten rdzeń musi mieć dostęp do całości, zarówno w fazie rozwoju, jak i produkcji. Są twoimi partnerami w tworzeniu polityk bezpieczeństwa. Musimy zaakceptować fakt, że główni programiści są właścicielami firmy. Mój stary szef mawiał: "Mamy szczęście, że Lucas jest po naszej stronie, po drugiej stronie by nas zniszczył". Główni programiści mogą wyrządzić wiele szkód, jeśli chcą, i nie ma zapory sieciowej ani kontroli produkcji, które mogą temu zapobiec.
• Oddziel środowisko za pomocą zapór ogniowych : oddziel swoją sieć programistyczną od Twoja sieć testowa, z Twojej sieci produkcyjnej. W firmie zdefiniowałem sieć 10.1. jako rozwój, 10.2. jako testowanie i 10.3. jako produkcja. Sieci 10.2 i 10.3 otrzymują kod tylko przez korporacyjny CVS i tworzą go automatycznie na polecenie administratora. Mimo, że był to mały start-up i byłem na produkcji i w zespołach programistycznych, zrobiłem kilka biurokracji, aby uniknąć własnych błędów (deweloperzy mogą być Twoimi najlepszymi sprzymierzeńcami). Zmieniłem również kolory terminali według sieci: podczas łączenia się z serwerem produkcyjnym tło terminala było czerwone, testowanie było żółte, a programistyczny zielony. Ponieważ wszystkie moje serwery korzystały z tej samej konfiguracji, łatwo było je pomylić, jeśli monit był otwarty. Z mojego doświadczenia wynika, że ​​większość problemów wynika ze źle przetestowanego oprogramowania i nowych instalacji oprogramowania. Dla jasności: moim zdaniem to, gdzie jesteś, jest potężną funkcją bezpieczeństwa. Nie ma to nic wspólnego z dostępem, ale jest to bezpieczeństwo.
• Zatrudnij wykwalifikowanego programistę testów : kluczowym aspektem testowania jest posiadanie dużej ilości dobrych symulowanych danych, które są istotne dla problemów, z którymi boryka się firma. Symulacje Monte-Carlo są dobre do generowania dużych zbiorów danych, które mają znaczenie dla innych programistów i mogą prowadzić do silniejszego i odporniejszego oprogramowania i procesów. Dla mnie nie ma błędów „produkcyjnych”, zawsze winny jest deweloper. Należy spisać zadania związane z konserwacją i nieprzewidziane okoliczności. Oprogramowanie musi być odporne.
• Przegląd kodu źródłowego : poproś ludzi o przejrzenie kodu źródłowego przed zaakceptowaniem modyfikacji. Wszystkie projekty powinny być rozgałęzione na kontrolę kodu źródłowego, a scalanie powinno zostać sprawdzone. Przegląd kodu źródłowego powinien zajmować się tylko wykrywaniem złośliwego oprogramowania, eskalacją dostępu, profilami dostępu i dobrym wyjaśnieniem, co kod źródłowy oznacza i powinien robić. Jakość kodu zostanie zapewniona poprzez testowanie, a nie przegląd kodu źródłowego. Można to zobaczyć w akcji w większości projektów open source.
• Testy Polityki testowania są znacznie bardziej kulturą korporacyjną niż strukturą. Niektóre firmy przyjmują ramy rynkowe, przeprowadzają testy, ale jakość ich kodu jest zła. Dzieje się tak, ponieważ potrzebujesz ludzi zdolnych do tworzenia znaczących testów. W rzeczywistości rozwój musi być sterowany testami. Nie znam innej bezpiecznej drogi rozwoju. Ciekawe jest to, że ludzie, zakupy i doradztwo również muszą zostać przetestowane. Sprzedawcy często twierdzą, że ich produkty działają bez zarzutu, ale ja jeszcze nie znalazłem produktu bez wad.
• Zasady są bez znaczenia, jeśli nie są monitorowane . Pewna firma, którą znam, ma biurokrację, że każda tabela bazy danych powinna mieć opis na poziomie atrybutów. 95% atrybutów jest opisanych jako „$ {nazwa atrybutu} z $ {nazwa tabeli}”. Nie wyjaśnia, czym naprawdę jest ten atrybut, jakie wartości mogą posiadać i tak dalej.
• Odpowiednie wynagrodzenie i środowisko pracy . Aby mieć dobrych programistów, zarówno pod względem umiejętności, jak i osobowości, musisz mieć dobrą politykę wynagrodzeń. Pieniądze są oczywiście ważne, ale to nie wszystko. Musisz także mieć perspektywę / stabilność, prawdziwe uznanie i dobre środowisko pracy. Na przykład zamiast w biurze deweloperskim w Nowym Jorku, w którym ludzie mieszkają w małych mieszkaniach, można wybrać mniejsze miasto, w którym taka sama rekompensata pozwala na większy dom i bliskość miejsca pracy. Większe komputery, dobre laboratoria to także plus dla entuzjastów technologii.
• Bezpieczeństwo danych wiele czynności wymaga wrażliwych danych produkcyjnych i powinno się do nich dostać w specjalnym laboratorium. O ile informacje nie są publiczne lub nie są poufne, być może najlepszą polityką jest umieszczenie laboratoriów w dobrych okolicach z kontrolowanym dostępem fizycznym. Zezwalaj na umieszczanie tylko niektórych symulowanych danych na osobistych laptopach i komponentach, które nie są wrażliwe. To jest możliwe. Na przykład opracowałem 4,5 miliarda rekordów archiwum danych, do których dostęp jest ciężki, dla firmy. Zrobiłem w domu i nie wykorzystałem do tego celu żadnych danych firmowych. Kiedy przesłałem kod, działał zgodnie z oczekiwaniami za pierwszym razem. Oprócz awarii sprzętu i migracji środowisk produkcyjnych mamy 100% dostępności w ciągu 10 lat. Ryzyko, że programista zabierze ze sobą kod źródłowy, nie ma znaczenia. Opracowanie tego konkretnego systemu zajęło mi 3 miesiące, większość tego czasu poświęcono na zrozumienie ograniczeń wydajności komponentów. To jest teraz wiedza w mojej głowie. Nawet bez kodu źródłowego mogę ponownie opracować to rozwiązanie w ciągu około tygodnia.
• Silne dzienniki są ważne, aby wiedzieć, kto coś zrobił. Najlepiej jest generować dzienniki przez framework, rejestrując przez krótki czas szczegółowe ekrany, dla dłuższego dostępu i działań, a nawet dłuższe dzienniki korporacyjne. Moje krytyczne systemy rejestrują się za każdym razem, gdy uzyskuje się dostęp do ekranu (w tym projekt ekranu). Niektóre z krytycznych zasobów powinny być rejestrowane przez wyzwalacz w samej bazie danych, a krytyczne tabele lub zasoby powinny być oznaczone do kontroli kodu źródłowego.
  - Sprawdzanie dziennika jest trudne do wykonania ręcznie. Dowiedz się, jak tworzyć filtry w dziennikach, aby zobaczyć krytyczne rzeczy. Bardzo przydatnym filtrem jest krzyżowanie zgłoszeń skarg z dostępem i działaniami użytkowników. Jeśli masz wystarczająco dobre dzienniki, zobaczysz zbiegi okoliczności. Na przykład: przed wystąpieniem problemu użytkownik1 zawsze się loguje.

Informacje o braku dostępu do produkcji

Zasady, które wymagają od programistów dostępu do systemów produkcyjnych, ponieważ użytkownicy są po to, aby uniknąć przesłanie kodu w celu pokazania uprzywilejowanej informacji jego własnemu użytkownikowi. Myślę, że jest to bardzo, bardzo słaby środek bezpieczeństwa i łatwy do wykrycia podczas audytu kodu źródłowego. Jest kilka łatwych sposobów obejścia tego:

• programista plus jeden nisko opłacany pracownik;
• wyślij sobie e-mail;
• otwórz tylne drzwi w systemie.

Audyt kodu źródłowego pod kątem backdoorów, eskalacji dostępu i złośliwego oprogramowania wydaje się bardziej produktywny. Pozwala zidentyfikować złych programistów, gdy testują swoje exploity i zwolnić ich. Oczywiście wykwalifikowany programista może ukryć exploita na widoku, dlatego ważne jest, aby używać języków i nazw zmiennych w sposób jasny i przejrzysty. Stosuj dziwne rozwiązania tylko w udokumentowanych punktach aplikacji, które wymagają specjalnej wydajności lub zaciemnienia. Na przykład 1 << 4 to to samo, co 1 * 16. Miałoby to sens tylko wtedy, gdyby język sam nie przeprowadzał tej optymalizacji, a miejsce, w którym to się dzieje, jest wąskim gardłem wydajności. Zbyt symboliczne języki są złe z tego samego powodu. Kod źródłowy powinien być czytelny dla każdego maniaka.

Problem jest gorszy niż myślisz

Najłatwiejsze i najgorsze szkody, jakie może spowodować programista, nie są związane z instalacją narzędzia. Nawet jeśli środowisko programistyczne jest zarządzane, nie będzie miało większego znaczenia, jeśli firma nie ma silnych zapór ogniowych, repozytoriów kodu źródłowego, kompilacji opartych wyłącznie na repozytoriach kodu źródłowego i przeglądzie kodu.

Jako konsultant pracowałem dla wielu różnych firm i tylko 2 z nich nie przyznały programistom dostępu administracyjnego do swoich maszyn; jedna była małą firmą, druga bardzo dużą.

W małej firmie poprosiłem o dostęp administratora, wyjaśniłem dlaczego przez około 60 sekund i otrzymałem go od razu.

W dużej firmie poprosiłem o dostęp administracyjny i powiedziano mi, że chociaż zgadzają się, że powinienem go mieć, polityka firmy zabrania tego i nie mogą tego zmienić. Więc jeden z informatyków podszedł i utworzył konto administratora lokalnego na moim komputerze i kazał mi ustawić dla niego hasło. Odtąd za każdym razem, gdy potrzebowałem zostać administratorem, mogłem zalogować się do maszyny jako administrator lokalny lub po prostu użyć runas do uruchomienia programu Visual Studio lub dowolnej usługi / aplikacji, której potrzebowałem do uruchomienia z użytkownikiem administracyjnym (na przykład IIS). Nie jest to dużo gorsze niż wybranie wbudowanego „Uruchom jako administrator”; jest tylko trochę wolniejszy, ale na szczęście nie pojawia się zbyt często.

Pamiętaj, że większym problemem związanym z bezpieczeństwem jest wyciek adresu IP, a nie złośliwego oprogramowania. Miejmy nadzieję, że masz IDS / IPS na miejscu, aby poradzić sobie z tym drugim, co powinno sprawić, że nie będzie to problemem.

Możesz uciec z udzieleniem administratorowi dostępu do sprzętu deweloperskiego, pod warunkiem, że masz na miejscu: / p>

• Anti-eDLP (sieć, USB itp.)
• IDS / IPS
• Firmowy serwer proxy z uwierzytelnianiem MITM NTLM, przez który wymuszasz wszystkie połączenia i monitorujesz za naruszenia DLP
• Odrzuć wszelkie oprogramowanie do wirtualizacji na komputerach stacjonarnych. Jeśli potrzebujesz maszyny wirtualnej, zapewnij ją z zarządzanej chmury, dzięki czemu wszystkie maszyny wirtualne będą uruchamiać ten sam przestarzały, ustandaryzowany obraz z powyższymi narzędziami.
• Zablokuj dostęp do zewnętrznych repozytoriów oprogramowania na poziomie sieci (to paruje pip, git, maven, apt, yast, zypper i wszystko inne)
• Zablokuj dostęp do github, codeplex i wszystkich 150 innych stron udostępniających kod na poziomie sieci
• Zablokuj dostęp do wszystkie ponad 9000 witryn do udostępniania plików na poziomie sieci
• Blokuj dostęp do P2P ... itd ...

To wszystko i więcej robi mój pracodawca. Wielu kolegów i tak kończy pracę na własnym sprzęcie osobistym po godzinach w domu i wyrzuca go z powrotem przez płot bocznymi kanałami, aby ominąć uszkodzoną infrastrukturę. Osobiście wolałbym spędzać wieczory pijąc i marząc o przedawkowaniu środków uspokajających dla psów, niż tracić dodatkowe nieudokumentowane 20 godzin na robienie czegoś, co i tak by mnie zwolniło.

Rozważamy informatykę (a co za tym idzie, inżynierię oprogramowania ) nauka. Eksperymenty naukowe przeprowadza się w sterylnych warunkach, aby kontrolować zmienne. Rozwój w okaleczonym środowisku, w którym rzeczy nie działają zgodnie z oczekiwaniami, nie jest naukowy. Z doświadczenia mogę powiedzieć, że nie daje się z tego dobrze zaprojektowanego oprogramowania ... wszystko, co opracowano wewnętrznie, jest zepsute, co prowadzi do większych wydatków na rozwiązania innych firm.

Programiści absolutnie muszą mieć sterylne środowisko, w którym mogą się rozwijać. Nie mogę powiedzieć, ile razy różne mechanizmy zabezpieczeń wprowadziły gremliny do architektury deweloperskiej i produkcyjnej - dlatego zarządzane, sterylne, oparte na chmurze środowisko programistyczne jest tak naprawdę jedyna droga. „To zadziałało w laboratorium, problem musi być czymś zewnętrznym”.

Musisz tylko upewnić się, że maszyny wirtualne, które im udostępniasz, nie są anemiczne i musisz zautomatyzować proces udostępniania a la OpenStack lub AWS, aby deweloperzy nie czekali dniami na zaspokojenie potrzeb związanych ze skalowaniem. Posiadanie ich wszystkich centralnie zarządzanych daje dużą kontrolę nad audytem i, szczerze mówiąc, daje programistom lepszą wydajność niż uzyskaliby na własnym sprzęcie.

Jestem fanem opcji nr 2: mieć oddzielne komputery.

Umożliwienie komputerom firmowym z zastrzeżonymi informacjami na połączenie z Internetem otwiera drzwi dla hakerów. Ułatwia to również pracownikom znacznie łatwiejsze wyprowadzanie danych firmy do nielegalnych celów.

Jeśli pracownik musi korzystać ze specjalnej maszyny w celu uzyskania dostępu do zasobów internetowych, tworzy kontrolowaną ścieżkę infiltracji i eksfiltracji danych, która jest dużo bezpieczne. Ponadto zniechęca pracowników do bezczynnego przeglądania sieci lub marnowania czasu na forach internetowych, tak jak robię to teraz.

Jako administrator ten problem został całkowicie i całkowicie rozwiązany dzięki podejściu SaaS. Zwirtualizuj wszystkie swoje środowiska, umieść je w szafie serwerowej odpowiedniej dla liczby klientów i skonfiguruj dostęp zdalny (RDP, usługi terminalowe lub inne ...). Teraz wszystko jest na serwerze i masz tylko jedno środowisko do obsługi dla wszystkich.