Przeniesienie środowiska do chmury poprowadzone tak, żeby po drodze nie przenieść starych problemów bezpieczeństwa — ani nie stworzyć nowych.
Termin migracji zostaje, a stan docelowy nie jest prowizorką.
Tak wygląda punkt wyjścia w wielu firmach, które dowożą szybko i podlegają regulacjom.
Migracja rozliczana jest z terminu i z tego, czy aplikacja wstała. Bezpieczeństwo wchodzi po fakcie, gdy środowisko już działa i każda zmiana oznacza przestój. Uprawnienia nadane „na czas migracji" zostają na zawsze, a konfiguracja z pośpiechu staje się stanem docelowym.
Zakres ustalamy po diagnozie — zaczynamy od elementu, który najszybciej obniży Wasze ryzyko.
Migracja to najtańszy moment na sprzątanie.
Zaczynamy od przeglądu stanu wyjściowego — co przenosicie, co powinno zostać na miejscu, a co warto przy okazji wyłączyć, bo przenoszenie martwych systemów kosztuje dwa razy. Środowisko docelowe projektujemy opisane kodem: podział na strefy, tożsamości, sieć i dostępy powstają przed pierwszym zasobem, nie po nim. Podczas migracji pracujemy ramię w ramię z Waszym zespołem albo dostawcą i pilnujemy warstwy bezpieczeństwa, którą zwykle robi się na końcu. Po przeniesieniu odbieramy uprawnienia tymczasowe i utrwalamy konfigurację, żeby stan z pośpiechu nie stał się docelowy.
Po każdym etapie zostaje u Was konkretny rezultat, a nie notatka ze spotkania.
Co przenosicie, co powinno zostać, a co warto przy okazji wyłączyć. Migracja to najtańszy moment na sprzątanie.
RezultatInwentarz: co przenosicie, co zostaje, co wyłączacie
Podział na strefy, tożsamości, sieć i dostępy — opisane kodem, zanim cokolwiek powstanie.
RezultatŚrodowisko docelowe opisane kodem, zanim powstanie pierwszy zasób
Pracujemy ramię w ramię z Waszym zespołem lub dostawcą migracji i pilnujemy warstwy bezpieczeństwa, którą zwykle robi się na końcu.
RezultatWarstwa bezpieczeństwa dowieziona razem z migracją, a nie po niej
Uprawnienia tymczasowe odbierane, dostępy zweryfikowane, konfiguracja utrwalona w kodzie.
RezultatOdebrane uprawnienia tymczasowe i protokół odbioru
Wdrożenie kończy się działającą konfiguracją i dowodami, a nie raportem z listą zaleceń. Tak to wygląda na przykładzie.
{
"Effect": "Deny",
"NotAction": ["iam:*", "organizations:*", "sts:*"],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["eu-central-1", "eu-west-1"]
}
}
}Żaden zasób nie powstanie poza uzgodnionymi regionami UE — nawet przez pomyłkę.
| System | Decyzja |
|---|---|
| aplikacja dla klientów | przenosimy do sieci prywatnej |
| stary panel raportów | wyłączamy |
| serwer plików | zostaje, decyzja po migracji |
Martwe systemy nie są przenoszone za podwójne pieniądze.
Stan po migracji jest sprawdzony, a nie założony.
Ilustracja. Zakres i narzędzia dobieramy po diagnozie.
Zakres ustalamy po rozmowie i diagnozie. Mniejsze wdrożenia zamykają się w kilku tygodniach, większe dzielimy na etapy, żeby efekt był widoczny po pierwszym.
Zwykle nie do całego. W większości przypadków wystarczy dostęp do konfiguracji procesu budowania i ustawień organizacji. Zakres ustalamy pisemnie przed startem.
Tak, ale nie na pełen etat. Potrzebujemy kontaktu z osobą, która zna system, i przeglądu naszych zmian. Reszta jest po naszej stronie.
Wpinamy się w to, co u Was działa. Wymiana narzędzia to najdroższy i najrzadziej potrzebny sposób poprawy bezpieczeństwa.
Nie. Pracujemy na standardach i narzędziach, które Wasz zespół zna albo szybko pozna — nie na autorskiej metodyce, którą rozumiemy wyłącznie my. Wszystko jest udokumentowane i przekazane.
Tak wpinamy kontrole, żeby działały w tle. Jeśli któraś zaczyna blokować pracę, dostrajamy ją albo zmieniamy jej miejsce w procesie.