Zaufanie dostępu to zaufanie, które strona umieszcza w drugiej stronie, gdy druga strona uzyskuje dostęp do usług i zasobów zapewnianych przez pierwszą stronę. Kontrola dostępu i zasady dostępu były tradycyjnie wykorzystywane do realizacji tego zaufania. Jednak w scenariuszu przetwarzania w chmurze utrzymanie zaufania do dostępu staje się znacznie trudniejsze ze względu na obecność wielu stron, z których każda ma odmienne cele. Song demonstruje ten problem. W artykule omówiono relacje między stronami zaangażowanymi w aplikację chmurową. Stronami tymi są dostawca oprogramowania, dostawca danych, koordynator i dostawca zasobów. Oprogramowanie i dostawca danych przesyłają swoje oprogramowanie lub dane do zasobów udostępnionych przez dostawcę zasobów. Koordynator ułatwia wykrywanie usług, a dostawca zasobów zapewnia platformę do wykonywania oprogramowania na danych. Problem zaufania w architekturze pojawia się, gdy dostawca danych używa oprogramowania od dostawcy oprogramowania lub osoba trzecia chce korzystać z oprogramowania i danych. W takich przypadkach musi istnieć gwarancja, że używane oprogramowanie nie jest złośliwe i robi tylko to, co mówi (tj. W przypadku prywatnego zbioru danych oprogramowanie nie tworzy kopii danych znajdujących się za sceną). Problem z zaufaniem pojawia się również, gdy oprogramowanie jest dostarczane dostawcom danych, że nie tworzą oni nieautoryzowanych kopii oprogramowania. W artykule zaproponowano rozwiązanie oparte na logowaniu i izolacji. Dane od dostawcy danych i aplikacje, które mogą pracować na tych danych od dostawcy oprogramowania, są zaszyfrowane, a dostęp do kluczy uruchamia mechanizm logowania. Koordynator wykorzystuje mechanizm wykrywania usług do znajdowania odpowiedniego oprogramowania dla zbioru danych i odwrotnie. Dostawca zasobów zapewnia izolowane środowisko do działania aplikacji. Dostawca oprogramowania i dostawca danych nie znają swojej tożsamości i wiedzą tylko, że wykonanie jest wykonywane za pomocą identyfikatora odniesienia wykonania. Ten model, chociaż pomaga w rozliczalności i anonimowym wykonaniu, nie daje żadnej gwarancji, że oprogramowanie nie utworzy kopii danych. Jednak aby mieć pewność, że kopia oprogramowania będzie używana tylko w odniesieniu do zbioru danych, dla którego została przeznaczona i nie będzie kopiowana bez upoważnienia, autorzy proponują powiązanie zaufania oprogramowania i danych. Odbywa się to przez dostawcę zasobów przy użyciu modułu zaufanej platformy (TPM). Ponieważ dane są zaszyfrowane za pomocą klucza, każde konkretne wystąpienie oprogramowania jest modyfikowane tak, aby działało tylko z określonym kluczem. W związku z tym każda instancja będzie musiała zostać zmodyfikowana pod kątem nowego zestawu danych, a nieautoryzowana modyfikacja nie byłaby dozwolona przez moduł TPM. Sundareswaran proponuje zdecentralizowane ramy odpowiedzialności za informacje, aby śledzić faktyczne wykorzystanie danych użytkowników w chmurze. W artykule przedstawiono sposób traktowania zaufania dostępu do chmur, wykorzystując programowalne możliwości plików Java JAR w celu dołączenia mechanizmów rejestrowania do danych i zasad użytkowników. Aby poprawić kontrolę użytkownika nad danymi, zapewniają mechanizmy kontroli rozproszonej. W scenariuszu przetwarzania w chmurze, ponieważ dane przechodzą przez zasoby (sprzęt i oprogramowanie) należące do różnych podmiotów, konwencjonalne przetwarzanie danych nie może zagwarantować odpowiedzialności i prywatności danych. Autorzy proponują odpowiedzialność za informacje w chmurze (CIA), aby rozwiązać te problemy. CIA ma dwa główne komponenty, rejestrator i harmonizator dziennika. Główne zadania rejestratora obejmują automatyczne rejestrowanie dostępu do zawartych w nim elementów danych, szyfrowanie zapisów dziennika i okresowe wysyłanie ich do harmonizatora dziennika. Za audyt odpowiedzialny jest harmonizator dziennika. Architektura ma dwa pliki JAR; zewnętrzny JAR i wewnętrzny JAR. Zewnętrzny plik JAR zawiera zasady dostępu, a wewnętrzny plik JAR zawiera zaszyfrowane rzeczywiste dane w kilku plikach JAR. Zasady dostępu określają dostęp do wewnętrznych plików JAR za pomocą metod takich jak czas dostępu i dostęp oparty na lokalizacji. Mechanizm ten może przetrwać różne ataki, takie jak atak kopiujący, w którym osoba atakująca kopiuje pliki JAR, atak polegający na dezasemblacji, podczas którego plik JAR ma zostać zdemontowany, atak typu man in the middle oraz atak na skompromitowaną wirtualną maszynę Java (JVM). Przyjrzyj się odpowiedzialności w chmurze z innej perspektywy. W artykule omówiono kluczowe kwestie i wyzwania związane z uzyskaniem zaufanej chmury przy użyciu mechanizmów kontroli detektywistycznej oraz przedstawiono strukturę TrustCloud do radzenia sobie z zaufaniem do dostępu. W artykule omówiono wyzwania związane z wirtualizacją, rejestrowaniem z perspektywy systemów operacyjnych w porównaniu z rejestrowaniem z perspektywy systemów skoncentrowanych na plikach, skalą, zakresem i wielkością rejestrowania oraz pochodzeniem danych. Ich struktura TrustCloud ma różne warstwy abstrakcji; warstwa systemu, która zajmuje się systemami operacyjnymi, systemami plików i wewnętrzną siecią chmury; warstwa danych, która wspiera abstrakcję danych i ułatwia centralne rejestrowanie danych poprzez rejestrator pochodzenia i rejestrator spójności; warstwa przepływu pracy, która koncentruje się na ścieżkach audytu i danych związanych z audytem znajdujących się w usłudze oprogramowania w chmurze. W ramach istnieje warstwa polityki, prawa i regulacji, która obejmuje wszystkie trzy warstwy. Sposób przechowywania danych, kto uzyskuje do nich dostęp, gdzie dane są przechowywane, jest objęty tymi zasadami. Podsumowując, niniejszy artykuł dobrze poradził sobie ze wszystkimi kwestiami, które dotychczas nie były poruszane w literaturze dotyczącej chmury obliczeniowej