Ten artykuł jest również dostępny w:
Niniejszy dokument zawiera wytyczne dotyczące sposobu, w jaki Easy LMS utrzymuje bezpieczeństwo i prywatność swoich klientów.

Bezpieczeństwo składa się z warstw, a my mamy pięć zasad przewodnich, które pozwalają nam mieć więcej i lepsze warstwy bezpieczeństwa w naszej organizacji i naszym produkcie. Każda z tych pięciu zasad zostanie omówiona oddzielnie w niniejszym dokumencie. Nasze pięć głównych zasad bezpieczeństwa to:

Priorytetowa zasada bezpieczeństwa
Omówienie zasady bezpieczeństwa
Nie ma zasady nieutrzymywanego oprogramowania
Co najmniej zasada 4 + 2 oczu
Zasada mniej uprzywilejowanego dostępu

Priorytetowa zasada bezpieczeństwa

Cokolwiek zrobimy, najpierw naprawimy ochronę.

Żaden element oprogramowania nie jest pozbawiony błędów, i chociaż dokładamy wszelkich starań, aby mieć najwyższą możliwą jakość naszego produktu, nie jesteśmy od tego wyjątkiem. Oznacza to, że czasami znajdujemy (potencjalne) problemy z bezpieczeństwem w naszym systemie. Za każdym razem, gdy problem pojawia się w naszej instalacji produkcyjnej, zalogowany błąd ma najwyższy priorytet, aby upewnić się, że nie ma zaległości w rozwiązaniu problemów bezpieczeństwa. W przypadku wykrycia wielu problemów z bezpieczeństwem, pierwszeństwo ma problem bezpieczeństwa o najwyższej wadze.

W scenariuszu, w którym problem bezpieczeństwa zostaje wykryty przed jego pojawieniem się w naszym środowisku produkcyjnym, istnieje proces mający na celu zapewnienie, że dalsze wdrażanie podatnego na zagrożenia kodu zostanie uniemożliwione do czasu rozwiązania problemu bezpieczeństwa. Ponieważ może to powstrzymać nas przed wdrożeniem nowych funkcji, kwestie te są również traktowane priorytetowo przy naprawach.

Często mówimy, że bezpieczniej jest być bezpieczniejszym niż przepraszać. Uważamy, że zapewnienie bezpiecznego produktu nie polega na naprawianiu napotkanych problemów, ale na upewnieniu się, że problemy te nigdy nie będą istniały w pierwszej kolejności. Dlatego też uważamy, że bezpieczeństwo powinno być priorytetem już od najwcześniejszych etapów rozwoju, aby projektować zabezpieczenia bezpośrednio w naszym produkcie, a nie łatać rzeczy po nim.

Przedyskutujcie zasadę prywatności/bezpieczeństwa

Jeśli nie będziemy myśleć i dyskutować o tym, jak się poprawić, nigdy tego nie zrobimy.

Chociaż bezpieczeństwo jest omawiane i wdrażane w samym sercu naszego oprogramowania, uważamy, że zawsze jest miejsce na ulepszenia. Rozmowa pomaga nam skupić się na tym, jak podchodzimy do kwestii bezpieczeństwa. Ponadto, dyskusja jest sposobem na przekształcenie dobrych pomysłów w świetne pomysły, a dobrych projektów w świetne projekty. Co ważniejsze, ponieważ zawsze jest miejsce na poprawę, dyskusja może pozwolić nam dowiedzieć się, co potrzebujemy poprawić, a nie co _możemy poprawić. Bezpieczeństwo jest zawsze tak samo silne jak najsłabsza część, a jeśli chodzi o poprawę bezpieczeństwa, tylko poprawa najsłabszej części rzeczywiście poprawi bezpieczeństwo. Dlatego też wierzymy, że trwająca konwersja powinna być zawsze utrzymywana przy życiu na temat tego, co jest naszą najsłabszą częścią i jak możemy to poprawić.

Nie ma zasady nieutrzymywanego/niezabezpieczonego oprogramowania

Nasze oprogramowanie nie jest bezpieczne, jeśli platforma, na której działa, nie jest bezpieczna.

Nie wymyśliliśmy koła, a na pewno nie napisaliśmy własnego systemu operacyjnego. Więc, tak, jesteśmy zależni od kodu osób trzecich. Oznacza to, że musimy się również upewnić, że ten kod jest bezpieczny. Dla systemu operacyjnego (smak linuksa), środowiska języka programowania (php / węzeł), naszego serwera http (apache) i systemów baz danych (MariaDB), upewniamy się, że zawsze używamy wersji, która at least nadal otrzymuje poprawki bezpieczeństwa. Oznacza to, że nasze oprogramowanie jest regularnie aktualizowane w celu uruchomienia na aktualnej wersji. Ponadto, upewniamy się, że pozostajemy bezpieczni przez cały czas, ponieważ dla tych komponentów wymagamy, aby poprawki bezpieczeństwa były instalowane automatycznie.

W przypadku bibliotek, które wykorzystujemy w naszym kodzie, stosujemy zautomatyzowane narzędzia, gdy tylko jest to możliwe, aby zapewnić, że posiadają one aktualną, ale co ważniejsze, bezpieczną wersję. W praktyce stosujemy 'audyt npm', aby upewnić się, że nasze pakiety node.js są aktualne. I używamy 'roave/security-advisors', aby upewnić się, że nasze biblioteki php są bezpieczne.

Co najmniej zasada 4 + 2 oczu

Każda zmiana, bez względu na to jak banalna może się wydawać, musi być zweryfikowana pod względem jakości.

Aby utrzymać jakość, do której dążymy, uważamy, że bez względu na okoliczności, nasze oprogramowanie nie powinno być nigdy przyspieszane. Oznacza to, że każda zmiana wprowadzana do naszego produktu wymaga pełnego cyklu przeglądu. Oznacza to, że kod musi być widziany i zatwierdzany przez co najmniej dwóch programistów, a następnie testowany przez jeden z naszych zespołów testujących. Ta zasada jest zakorzeniona w naszym przepływie pracy. Zanim kod zostanie wdrożony do środowiska inscenizacyjnego lub produkcyjnego, musi przejść proces pull request. Żądania pull muszą być przejrzane przez co najmniej innego programistę. Faktyczne ponowne połączenie jest wykonywane przez kogoś z naszego zespołu testowego. W związku z tym, deweloper w zasadzie nie jest w stanie ponownie scalić pull request'u. Bezpieczeństwo jest (oczywiście) częścią cyklu przeglądu. Drugi programista oceni kod, aby sprawdzić, czy istnieją problemy związane z bezpieczeństwem. Tester testuje również pod kątem częstych błędów bezpieczeństwa, aby zapobiec niepotrzebnym wyciekom do naszego systemu.

Szczególną uwagę należy zwrócić na administrowanie infrastrukturą/systemem. Ponieważ cykl rozwoju kodu pozwala na ocenę bezpieczeństwa i jakości zanim trafi on do produkcji, staramy się zarządzać naszą pełną infrastrukturą jako kodem. Pozwala nam to na automatyzację większości funkcji, co oznacza, że popełniamy mniej ludzkich błędów. Ponadto, jeden administrator systemu może dokonywać zmian bez powiadamiania, które mogłyby wpłynąć na bezpieczeństwo naszego systemu.

Zasada najmniej uprzywilejowanego dostępu

Każdy człowiek musi mieć dostęp tylko do tego, czego potrzebuje, a każdy program powinien mieć dostęp tylko do tego, czego potrzebuje.

Najbardziej wiarygodnym sposobem zapobiegania wszelkim formom wycieku danych jest upewnienie się, że nie ma żadnych danych do wycieku. Następną najlepszą rzeczą jest upewnienie się, że nikt nie ma dostępu do niepotrzebnych informacji. Na przykład, deweloper nie potrzebuje dostępu do naszych danych produkcyjnych, aby rozwijać nowe funkcje. Podobnie, tłumacz musi tylko zobaczyć, co może zostać przetłumaczone w naszym systemie i nie potrzebuje dostępu do naszej bazy kodów ani informacji o klientach. Dążymy do tego, aby każdy w naszej organizacji widział i wykonywał tylko te zadania, które są wymagane do jego roli.

Zasada najmniej uprzywilejowanego dostępu dotyczy ludzi, ale ma również zastosowanie do systemów i usług. Jeśli jakaś część naszego systemu zostanie narażona na szwank, staramy się zminimalizować wpływ, jaki może ona mieć. Dlatego staramy się oddzielić usługi, które mogą mieć dostęp tylko do tych informacji, których potrzebują. Na przykład, nie musimy przetwarzać informacji o płatnościach podczas wyświetlania treści edukacyjnych. Dlatego też systemy odpowiedzialne za treści edukacyjne nie powinny mieć dostępu do naszego systemu płatności. Co więcej, jest to również możliwe w przypadku innych usług. W miarę możliwości staramy się odłączyć usługi od publicznego Internetu. Najlepiej zrobić to poprzez umieszczenie usług w prywatnej sieci, z której można uzyskać do nich dostęp tylko z tej sieci. Jeśli usługa nie jest przeznaczona do użytku publicznego, ale ma być dostępna przez Internet, pracujemy z białą listą adresów IP, aby zminimalizować narażenie.

Notatki końcowe

Uważamy, że do utrzymania wysokiego poziomu bezpieczeństwa konieczny jest ciągły wysiłek. Wysiłek ten oznacza, że nie powinien pozostawać w zgodzie z zasadami, ale że zasady te powinny być wbudowane we wszystkie nasze procesy przepływu pracy. W ten sposób możemy mieć pewność, że bezpieczeństwo ma pierwszeństwo w naszej organizacji.
Czy ten artykuł był pomocny?
Anuluj
Dziękuję!