Jak już wspomniano, chmury to duża pula łatwych w użyciu i dostępnych zwirtualizowanych zasobów, takich jak sprzęt, platformy programistyczne i / lub usługi. Te zasoby mogą być dynamicznie rekonfigurowane, aby dostosować się do zmiennego obciążenia (wagi), co pozwala również na optymalne wykorzystanie zasobów. Ta pula zasobów jest zwykle wykorzystywana przez model płatności za użycie, w którym gwarancje są oferowane przez dostawcę infrastruktury w ramach dostosowanych umów SLA. StaaS jest ogólnie postrzegany jako dobra alternatywa dla małej lub średniej firmy, która nie dysponuje budżetem kapitałowym i / lub personelem technicznym do wdrożenia i utrzymania własnej infrastruktury magazynowej. Jednak praktycznie nie ma kontroli nad danymi po ich zapisaniu, a jedynym zabezpieczeniem jest umowa SLA zapewniana przez dostawcę usługi przechowywania w chmurze, ale co się stanie po zakończeniu umowy SLA? Rozważmy scenariusz, w którym klient chmury (użytkownik końcowy / przedsiębiorstwo) chce przechowywać wrażliwe dane w chmurze u dostawcy / dostawcy pamięci masowej w chmurze przez określony czas. Teraz pod koniec określonego czasu lub okresu dzierżawy klient chmury chce wycofać dane i odciąć się od usługodawcy. Dostawca zgodnie z umową SLA zwróci dane klientowi lub usunie je z magazynu zgodnie z wymaganiami. Powstaje pytanie, jeśli dostawca twierdzi, że usunął dane ze swojej infrastruktury, jaki dowód ma klient chmury, że dane całkowicie opuściły infrastrukturę pamięci dostawcy? Klient chmury będzie musiał zapewnić kompleksowe zniszczenie tych danych z magazynu, szczególnie danych wrażliwych, które mogą podlegać wymaganiom regulacyjnym. Mimo że podstawową ochronę prywatności zapewnia szyfrowanie danych przed ich przechowywaniem, a nawet po zapewnieniach dostawcy, że dane zostały całkowicie usunięte / uczynione bezużytecznymi z jego dysków, obecnie nie ma metodologii, aby to zweryfikować. Spowoduje to problemy, jeśli infrastruktura zarządzania danymi dostawcy nie będzie zgodna z wymaganiami klienta dotyczącymi niszczenia (np. Dostawca jest w stanie usunąć najnowszą wersję, ale nie może usunąć danych ze zarchiwizowanej pamięci) i jakaś forma pozostałych danych ulegnie zniszczeniu ostatni do wycieku danych. Przykładem takiego ataku może być odzyskanie rzekomo skasowanych danych z nośników magnetycznych lub pamięci o dostępie swobodnym.
Wyzwania związane z niszczeniem danych
Niszczenie danych i ich walidacja nie są niczym nowym w dziedzinie elektroniki cyfrowej. Na rynku dostępne są również różne narzędzia skoncentrowane na niszczeniu i sprawdzaniu poprawności danych. Mimo że istnieje wiele technologii dotyczących niszczenia danych [12,13], wśród dostępnych różnorodnych narzędzi programowych, rozwiązań i systemów wdrażających techniki niszczenia danych, większość z nich ma pewne poważne wady, jeśli chodzi o scenariusz chmury / StaaS. Chmura zapewnia prawie nieskończoną przestrzeń wirtualną. Tak więc, w przeciwieństwie do samodzielnego systemu, w którym ograniczona przestrzeń wymaga ponownego wykorzystania, możliwość wystąpienia takiego scenariusza w chmurze jest znacznie mniejsza. Zatem wymyślenie metody niszczenia danych dla chmury, która w rzeczywistości jest zbiorem niezależnych maszyn pracujących w sposób rozproszony, może na początku wydawać się zbędna. Ale poniżej przedstawiono powody, dla których taki mechanizm niszczenia danych musi zostać opracowany niezależnie dla scenariusza StaaS.
Uprawnienia administratora dotyczące działań związanych z niszczeniem
Typowe algorytmy niszczenia danych zostały zaprojektowane z myślą o systemach autonomicznych, w których zakłada się, że osoba, która zhreduje dane, jest jedynym właścicielem / administratorem dysku twardego, a zatem ma prawo do manipulacji na poziomie bitowym i niszczenia. Jednak w środowisku chmurowym właściciel dysku z danymi i klient niszczący dane to różne osoby. Dlatego pojawia się potrzeba, gdy właściciel przestrzeni danych musi udzielić klientowi wyraźnych uprawnień dostępu do mechanizmów przechowywania danych na poziomie bitów, co wiąże się z ogromnymi problemami dotyczącymi bezpieczeństwa. W związku z tym należy opracować rozwiązania umożliwiające rozwiązanie tego problemu, w ramach którego dostawca będzie miał uprawnienia do zaprogramowania ilości danych, które klient może zniszczyć itp. Tradycyjne metody niszczenia danych nie mają na to możliwości.
Wysokie nakłady kapitałowe
Ponadto istniejące produkty do niszczenia danych są ograniczone z perspektywy klienta lub dostawcy lub obu. Produkty do niszczenia danych wymagają dużych początkowych nakładów kapitałowych ze względu na koszty rozwoju, a zatem stanowią duże ryzyko. Do uruchamiania tych samodzielnych aplikacji wymagany jest specjalny sprzęt, co z kolei wiąże się z kosztami ogólnymi, które z kolei przewyższają cel redukcji kosztów według modelu płatności za użytkowanie. Przedstawia obawy, takie jak planowanie operacji niszczenia, przywracanie po awarii i ciągłość działania lub fizyczny dostęp do usług niszczenia danych przez osoby nieupoważnione.
Ciągła konserwacja
Regularne aktualizacje lub poprawki błędów stają się uciążliwe w przypadku nieautonomicznego narzędzia, ponieważ są ściśle zintegrowane z innymi procesami. Również w przypadku dostawców produkt samodzielny przedstawia obawy związane z piractwem, wdrażaniem, takie jak tworzenie instalatorów oraz problemy z integracją, ponieważ wymaga integracji z działającymi procesami. Problemy z wersjonowaniem występują również w przypadku niestandardowego produktu do niszczenia danych; nowa wersja może nie być kompatybilna z istniejącym systemem operacyjnym, sprzętem itp. Nowa wersja musi również zostać przetestowana pod kątem integracji ze wszystkimi obsługiwanymi usługami. Zatem powyższe czynniki pokazują, że na niszczenie danych w konfiguracji StaaS należy spojrzeć z innej perspektywy. Proponowany mechanizm zapewnia sieciowy dostęp do usługi niszczenia danych i zarządzanie nią zarządzaną z centralnych lokalizacji, a nie w siedzibie każdego klienta. Umożliwia to klientom zdalny dostęp do usługi niszczenia za pośrednictwem aplikacji internetowej.
Możliwości skutecznego niszczenia danych – możliwa metodologia
Klienci chmury wymagają mechanizmów technicznych do niszczenia danych bez pomocy dostawcy lub osoby trzeciej. Klient powinien również mieć możliwość uzyskania potwierdzenia o zniszczeniu danych za pomocą modułu weryfikowalności. Ponadto może to być świadczone jako niezależna usługa w chmurze, a nie jako uzupełnienie przez dostawcę usług, ze względu na poziom nieodłącznej nieufności i wątpliwości, które towarzyszą konfiguracji przechowywania w chmurze. W tej sekcji przedstawiamy możliwości i strategię niszczenia danych w środowisku rozproszonym. Badamy również opcję, jeśli infrastruktura pamięci masowej może zostać zmodyfikowana w taki sposób, że wymaga takiej możliwości jak twarde wymazanie wraz z dowodem, na koniec okresu przechowywania. Skuteczne i wydajne metodologie niszczenia danych obejmują różne fazy w całym cyklu życia danych. Typowe fazy efektywnego niszczenia danych powinny rozpoczynać się od ustanowienia efektywnych umów SLA, a kończyć weryfikacją zniszczenia danych (po wygaśnięciu umowy SLA). W kolejnych podrozdziałach omówimy jedną możliwą metodologię, jej różne fazy i typowe działania w każdej fazie, aby osiągnąć efektywne niszczenie danych.