Ten artykuł jest również dostępny w:
Ten artykuł został przetłumaczony przy użyciu tłumaczenia maszynowego. Może zawierać błędy lub dziwnie brzmiące tłumaczenia. Mimo to uważamy, że warto go przeczytać w swoim ojczystym języku. Daj nam znać, czy ten artykuł okazał się pomocny, lub przekaż inne uwagi u dołu artykułu.

Niniejszy dokument zawiera zasady, którymi Easy LMS kieruje się w dbaniu o bezpieczeństwo i prywatność naszych klientów.

Bezpieczeństwo ma swoje warstwy, a my mamy pięć głównych zasad, 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 osobno w tym dokumencie. Nasze pięć głównych zasad bezpieczeństwa to:

Zasada ustalania priorytetów bezpieczeństwa
Omów zasadę bezpieczeństwa
Zasada nieutrzymywanego oprogramowania
Zasada co najmniej 4 + 2 oczy
Zasada najmniej uprzywilejowanego dostępu

Zasada ustalania priorytetów bezpieczeństwa

Cokolwiek robimy, najpierw naprawiamy bezpieczeństwo.

Żadne oprogramowanie nie jest pozbawione błędów i mimo, że dokładamy wszelkich starań, aby jakość naszych produktów była jak najwyższa, nie jesteśmy tu wyjątkiem. Oznacza to, że czasami znajdujemy (potencjalne) problemy z bezpieczeństwem w naszym systemie. W każdym przypadku, gdy problem jest obecny w naszej instalacji produkcyjnej, zgłoszony błąd jest traktowany priorytetowo, aby zapewnić, że nie ma zaległości w rozwiązywaniu nierozwiązanych problemów bezpieczeństwa. Jeśli zostanie znalezionych kilka problemów bezpieczeństwa, wtedy priorytet ma ten o najwyższym stopniu ważności.

W scenariuszu, w którym błąd bezpieczeństwa zostaje wykryty zanim wyląduje na naszym środowisku produkcyjnym, istnieje proces zapewniający, że dalsze wdrożenia podatnego kodu zostaną uniemożliwione do czasu rozwiązania problemu bezpieczeństwa. Ponieważ może to powstrzymać nas przed wdrożeniem nowych funkcjonalności, takie błędy są również traktowane priorytetowo w celu ich naprawienia.

Często mówimy, że "lepiej być bezpiecznym niż żałować". Uważamy, że zapewnienie bezpieczeństwa produktu nie polega na łataniu napotkanych problemów, ale na upewnieniu się, że te problemy nigdy nie zaistniałyby w pierwszej kolejności. Dlatego też uważamy, że bezpieczeństwo powinno być priorytetem już od najwcześniejszych etapów rozwoju produktu, aby zaprojektować bezpieczeństwo bezpośrednio w naszym produkcie, a nie łatać je później.

Omów zasady 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 sercu naszego oprogramowania, uważamy, że zawsze jest miejsce na ulepszenia. Rozmowa pomaga nam zachować skupienie i ostrość w podejściu do 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 ulepszenia, dyskusja może pozwolić nam dowiedzieć się, co musimy poprawić, a nie co możemy poprawić. Bezpieczeństwo jest zawsze tak silne, jak jego 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 ciągłe zastanawianie się nad tym, co jest naszym najsłabszym elementem i jak możemy to poprawić, powinno być zawsze żywe.

Zasada "Nie ma 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 już na pewno nie napisaliśmy własnego systemu operacyjnego. Tak więc, tak, jesteśmy zależni od kodu stron trzecich. Oznacza to, że musimy się również upewnić, że ten kod jest bezpieczny. W przypadku systemu operacyjnego (linux), środowiska języka programowania (php / node), naszego serwera http (apache) i systemu baz danych (MariaDB), upewniamy się, że zawsze używamy wersji, która co najmniej wciąż otrzymuje poprawki bezpieczeństwa. Oznacza to, że nasze oprogramowanie jest regularnie aktualizowane, aby działało na aktualnej wersji. Daje to również pewność, że pozostajemy bezpieczni przez cały czas, ponieważ dla tych komponentów wymagamy, aby poprawki bezpieczeństwa były instalowane automatycznie.

Dla bibliotek, których używamy w naszym kodzie, używamy zautomatyzowanych narzędzi, jeśli to tylko możliwe, aby zapewnić, że mają one aktualną wersję, ale co ważniejsze, wersję bezpieczną. W praktyce używamy 'npm audit', aby upewnić się, że nasze pakiety node.js są aktualne. Używamy też 'roave/security-advisors', aby upewnić się, że nasze biblioteki php są bezpieczne.

Zasada co najmniej 4 + 2 oczy

Każda zmiana, nieważne jak trywialna może się wydawać, musi być zweryfikowana pod względem jakości.

Aby utrzymać jakość, do której dążymy, wierzymy, że bez względu na okoliczności, nasze oprogramowanie nigdy nie powinno być pospieszne. Oznacza to, że dla każdej zmiany, którą wprowadzamy do naszego produktu, wymagany jest pełny cykl weryfikacji. Oznacza to, że kod musi być obejrzany i zatwierdzony przez co najmniej dwóch programistów, a następnie przetestowany przez jeden z naszych zespołów testujących. Ta zasada jest zakorzeniona w naszym przepływie pracy. Zanim kod zostanie wdrożony na środowisko produkcyjne, musi zostać zaakceptowany przez pull request. Pull requesty muszą być sprawdzone przez co najmniej jednego dewelopera. Faktyczne scalanie z powrotem jest wykonywane przez kogoś z naszego zespołu testującego. Z tego powodu, deweloper nie jest w zasadzie w stanie scalić z powrotem pull requesta. Bezpieczeństwo jest (oczywiście) częścią cyklu recenzji. Drugi deweloper oceni kod, aby sprawdzić, czy istnieją problemy związane z bezpieczeństwem. Tester testuje również typowe błędy bezpieczeństwa, aby zapobiec niepotrzebnym wyciekom do naszego systemu.

Szczególną uwagę należy zwrócić na infrastrukturę/administrowanie systemem. Ponieważ cykl rozwoju kodu pozwala na ocenę bezpieczeństwa i jakości zanim trafi on na produkcję, staramy się zarządzać całą naszą infrastrukturą jako kodem. Dzięki temu możemy zautomatyzować większość funkcji, co oznacza, że popełniamy mniej błędów ludzkich. Ponadto, pojedynczy administrator systemu może bez powiadomienia wprowadzać zmiany, które mogłyby wpłynąć na bezpieczeństwo naszego systemu.

Zasada najmniej uprzywilejowanego dostępu

Każda osoba musi mieć dostęp tylko do tego, co jest jej potrzebne, a każdy program powinien mieć dostęp tylko do tego, co jest mu potrzebne.

Najbardziej niezawodnym sposobem zapobiegania wszelkim formom wycieku danych jest upewnienie się, że nie ma żadnych danych, które mogłyby wyciec. Następną najlepszą rzeczą jest upewnienie się, że nikt nie może uzyskać dostępu do niepotrzebnych informacji. Na przykład, programista nie potrzebuje dostępu do naszych danych produkcyjnych, aby rozwijać nowe funkcje. Podobnie, tłumacz musi zobaczyć, co można przetłumaczyć w naszym systemie i nie potrzebuje dostępu do naszej bazy kodu lub informacji o klientach. Dążymy do tego, aby każda osoba w naszej organizacji mogła widzieć i wykonywać tylko te zadania, które są wymagane dla jej roli.

Zasada najmniej uprzywilejowanego dostępu odnosi się do ludzi, ale ma również zastosowanie do systemów i usług. Jeśli jakaś część naszego systemu zostanie naruszona, staramy się zminimalizować wpływ, jaki może to mieć. Dlatego staramy się wyodrębnić usługi, które mogą uzyskać dostęp tylko do tych informacji, które są im potrzebne. Na przykład, nie musimy przetwarzać informacji o płatnościach podczas wyświetlania treści edukacyjnych. W związku z tym systemy odpowiedzialne za treści edukacyjne nie powinny mieć dostępu do naszego systemu płatności. Co więcej, jest to możliwe również dla innych usług. Naszym celem jest odłączenie usług od publicznego Internetu, jeśli to możliwe. Najlepiej jest to zrobić poprzez umieszczenie usług w sieci prywatnej, z której mogą być dostępne 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ć ekspozycję.

Uwagi końcowe

Wierzymy, że ciągły wysiłek jest wymagany do utrzymania wysokiego poziomu bezpieczeństwa. Ten wysiłek oznacza, że nie powinno się pozostać przy zasadach, ale że te zasady powinny być wbudowane we wszystkie nasze procesy przepływu pracy. W ten sposób, możemy upewnić się, że bezpieczeństwo ma priorytet w naszej organizacji.
Czy ten artykuł był pomocny?
Anuluj
Dziękuję!