współdzielenie OneDrive – ciekawostki

OneDrive Sharing

na początek oczywiste oczywistości:

• OneDrive to de facto SharePoint. główne ustawienia współdzielenia [Sharing] dziedziczy z globalnych ustawień SP
• od jakiegoś czasu dostępny jest OneDrive Admin Center z poziomu Office365. z jego poziomu można pozornie ustawić zabezpieczenie współdzielenia na poziomie niższym, niż jest zdefiniowany w SharePoint. ale nie można [co zresztą jest opisane małym druczkiem na dole].

• od niedawna rozbudowany został klient OneDrive – w końcu można nadawać uprawnienia 'bezpośrednio’ z Exploratora. co mnie pozytywnie zaskoczyło – okienko uprawnień jest renderowane przez OneDrive.exe a nie, tak jak się spodziewałem, iexplore.exe/edge .

Jak powstaje ACE dla osoby z zewnątrz

i tu się zaczyna robić ciekawie. standardowo, do czego przyzwyczaiły nas systemy operacyjne, flow jest taki:

• użytkownik wybiera plik i nadaje uprawnienia
• tworzony jest ACE – Access Control Entry – który staje się nieodłączną częścią pliq… w dużym uogólnieniu.
• osoba próbuje się dostać
  • uwierzytelnia się
  • token uwierzytelniony porównywany jest z ACL [Access Control List] w poszukiwaniu ACE dla danego usera – rodzaj filtra
• osoba dostaje dostęp lub nie.

wydaje się tak oczywiste… a jednak dla pliq współdzielonego z osobą z zewnątrz w OneDrive, jest inaczej. czy zastanawiałeś się po co jest poniższa opcja? skoro można uzyskać dostęp przez osobę inną niż zaproszona, to znaczy, że ACE nie może istnieć w momencie dostępu. zakładając, że wyłączone są linki anonimowe, w dużym uogólnieniu wygląda to tak:

• użytkownik wybiera plik, uprawnienia edit/view i adres osoby z zewnątrz.
• tworzony jest *link*, URL, zawierający token dostępu. ten link wysyłany jest mailem.
• osoba, która otrzymała link otwiera go. zakładając, że wymuszone jest uwierzytelnienie, zostanie przekierowana na stronę logowania.
• po pozytywnym uwierzytelnieniu, na podstawie linka generowane jest ACE, które dopiero teraz dopisywane jest do pliq
• tworzone jest również konto [jeśli nie było wcześniej] „username_server.name#EXT#@company.onmicrosoft.com” w AAD

czemu tak i jakie to ma konsekwencje

opisywane zachowanie będzie zależne od kilq ustawień bezpieczeństwa na SP – czy włączone są linki anonimowe, oraz czy mogą być otwierane przez osoby inne, niż te, do których się je oryginalnie wysłało. współdzielenie linkiem jest znane od lat, i dość oczywiste, dla osób korzystających z usług chmurowych. po prostu w rozproszonym świecie chmury, gdzie nie ma centralnej bazy użytkowników, token jest przekazywany wraz z linkiem – w dużym skrócie posiadanie linka oznacza posiadanie dostępu. stąd powstały mechanizmy rozszerzające to rozwiązanie – np. o wymaganie uwierzytelnienia. czemu zatem link wysłany przez jedną osobę, standardowo może być otworzony przez inną? ta opcja została stworzona głównie z tego powodu, że ludzie korzystają z masy adresów, i mogą mieć konto MS Account założone z innym adresem niż my znamy – np. wysyłamy do kogoś na x@gmail.com a ktoś ma konto MS Account jako x@outlook.com. dzięki temu osoba nie jest zmuszona zakładać kolejnego konta, co było istotne zwłaszcza jakiś czas temu, kiedy nie istniał uproszony proces zakładania konta, i było to bardzo upierdliwe. ale ze względu na bezpieczeństwo, nie włączenie tej opcji, jest dość niepokojącym scenariuszem i sugerowałbym jednak, aby wymuszać weryfikację odbiorcy. w takim wypadq, nawet jeśli przekaże się linka innej osobie [lub zostanie wykradziony!], nie zostanie on obsłużony. można się przyczepić, że komunikat błędu pokazuje zdekodowany adres email osoby, która oryginalnie była w tokenie, ale nie jest to już tak wielki problem.  załóżmy, że opcja jest na 'default’, czyli może być otwarty przez inną osobę. co się stanie, jeśli roześlę link do stu osób? czy wszystkie będą miały dostęp? NIE. link zawiera 'token jednorazowego dostępu’. pierwsza osoba się dostanie i dla niej utworzony zostanie ACE, pozostałe osoby dostaną acc denied.

ciekawostki (bugs?)

nie może obyć się bez zagadek w-files. trafiłem na dwie. w porywach do trzech q:

1. jeśli jakiś user ma wpisany alternate email z jakimś adresem zewnętrznym – np. x@gmail.com, i chcemy udostępnić plik tej osoby na tenże adres zewnętrzny… to się nie uda. AAD rozpoznaje użytkownika jako wewnętrznego i co prawda wysyła linka [zależnie od tego z jakiego interfejsu skorzystamy zachowanie może być różne], ale nie ma szansy zalogować się na kontem x@gmail.com .
2. jak sądzicie, czy usunięcie konta #EXT# z AAD spowoduje, że osoba straci dostęp do pliq? scenariusz:

• administrator doszedł do wniosq, że posprząta trochę, i *dla bezpieczeństwa* usunie konta #EXT# żeby zabrać dostępy.

no to się zdziwi, ponieważ usunięcie konta, nie powoduje usunięcia ACE – te systemy są rozdzielne, i nie ma 'centralnego repozytorium dostępów’. a ponieważ centrum uwierzytelnienia jest również rozłączne z naszym systemem, user zostanie poprawnie uwierzytelniony [przez Microsoft Account a nie przez nasz tenant AAD], ACE istnieje – ergo dostęp będzie. nie wierzycie – spróbujcie, podzielcie się wrażeniami. właśnie ta część pracy – odpowiedź na pytanie 'kto ma gdzie dostęp’ – jest nadal niełatwym zadaniem. 3. PS. czy zwróciliście uwagę, że w OneDrive for Business jest ’shared with me’ a w OneDrive personal jest ’Shared by me’? i żadne ze środowisk nie udostępnia mechanizmu dla pełnego rozeznania się co komu i dla nas….  

OneDrive for Business

OneDrive personal

eN.