LinkedIn
Instagram
WhatsApp
Telegram
Kalendarz Google
Dołącz do społeczności SlackZintegruj skrzynki pocztowe, które Twoi użytkownicy mogą zaufanie
Łączenie się ze skrzynkami odbiorczymi użytkowników wiąże się z realnym ryzykiem bezpieczeństwa. Przechowywane hasła, zbyt szerokie zakresy OAuth i nietotowane tokeny tworzą powierzchnie ataku, które naruszają zaufanie użytkowników i są niezgodne z RODO.
Unipile Przewodnik po API poczty elektronicznej obejmuje pełny obraz integracji. Ten artykuł skupia się na warstwie bezpieczeństwa: co musi gwarantować bezpieczne API poczty e-mail, jakich zagrożeń należy unikać i w jaki sposób Unipile jest zaprojektowany, aby chronić dane użytkowników.
Gmail
Perspektywy
IMAP
Co sprawia, że API e-mail jest "bezpieczne"?
Bezpieczeństwo w API e-mailowym nie jest pojedynczą funkcją. Jest to wybór architektoniczny obejmujący uwierzytelnianie, autoryzację, obsługę danych i infrastrukturę. Bezpieczne API e-mailowe musi gwarantować jednocześnie cztery rzeczy.
Użytkownicy autoryzują dostęp za pomocą oficjalnego przepływu OAuth od swojego dostawcy. Żadne hasło nigdy nie opuszcza serwera dostawcy ani nie trafia do Twojej bazy danych.
Każde połączone konto żąda tylko niezbędnych mu uprawnień - tylko do odczytu, gdy nie jest potrzebne wysyłanie, zakres wysyłania tylko wtedy, gdy jest to wyraźnie wymagane.
Cały ruch API wykorzystuje TLS 1.2+. Zapisane tokeny są szyfrowane w spoczynku przy użyciu AES-256. Treść wiadomości e-mail nigdy nie jest utrwalana poza cyklem życia żądania.
OAuth 2.0 a przechowywanie hasła
Najbardziej fundamentalną decyzją dotyczącą bezpieczeństwa w każdej integracji poczty e-mail jest sposób uwierzytelniania. Wiele starszych integracji IMAP prosi użytkowników o podanie hasła do poczty e-mail i jego zapisanie. Takie podejście tworzy pojedynczy punkt awarii: jedno naruszenie bazy danych ujawnia skrzynkę odbiorczą każdego użytkownika. OAuth 2.0 całkowicie to eliminuje. Zobacz, jak Google OAuth 2.0 oraz Microsoft OAuth 2.0 zaimplementuj ten przepływ.
Zakresy tokenów: tylko do odczytu vs. wysyłanie
Zakresy OAuth precyzyjnie określają, co Twoja aplikacja może zrobić z pocztą użytkownika. Żądanie szerokich zakresów, gdy wystarczyłyby węższe, jest poważnym antywzorcem bezpieczeństwa. W przypadku systemu CRM, który tylko odczytuje wiadomości e-mail w celu rejestrowania aktywności, żądanie gmail.zmodyfikuj jest niepotrzebne i naraża użytkowników na większe ryzyko, jeśli Twój token zostanie skompromitowany. Jeśli Twoja aplikacja wymaga API do wysyłania e-maili żądania, znajdziesz również pełne zestawienie wymaganych zakresów dla każdego dostawcy w naszym przewodniku po API do wysyłania wiadomości e-mail.
| Zakres | Dostawca | Co to umożliwia | Poziom ryzyka |
|---|---|---|---|
| gmail.tylko_do_odczytu | Gmail | Przeczytaj e-maile | Minimalny |
| gmail.wyślij | Gmail | Wyślij w imieniu użytkownika | Zakres |
| Mail.Read | Perspektywy | Przeczytaj e-maile | Minimalny |
| Mail.Send | Perspektywy | Wyślij w imieniu użytkownika | Zakres |
| https://mail.google.com/ | Gmail | Pełny dostęp do skrzynki pocztowej | Szeroki |
| Mail.ReadWrite | Perspektywy | Czytaj, pisz, usuń | Szeroki |
Szyfrowanie w tranzycie i w spoczynku
Bezpieczne API poczty e-mail wymusza stosowanie TLS w wersji 1.2 lub nowszej na wszystkich punktach końcowych API. Komunikacja w postaci zwykłego tekstu nie jest akceptowalna. Poza transmisją, wszelkie tokeny lub dane uwierzytelniające, które muszą być przechowywane – na przykład tokeny odświeżania OAuth – muszą być szyfrowane podczas przechowywania przy użyciu silnego szyfrowania symetrycznego (AES-256). Równie ważne: sama zawartość wiadomości e-mail nigdy nie powinna być przechowywana dłużej niż jest to wymagane przez żądanie. Odczytanie i wyświetlenie wiadomości e-mail w interfejsie użytkownika nie wymaga utrwalania jej treści w bazie danych.
Ryzyka związane z bezpieczeństwem interfejsu API poczty e-mail, których należy unikać
Większość błędów związanych z bezpieczeństwem integracji poczty e-mail nie polega na wyrafinowanych atakach – są to przewidywalne błędy w sposobie obsługi poświadczeń, tokenów i danych. Cztery poniższe wzorce odpowiadają za większość incydentów w świecie rzeczywistym w zakresie integracji API poczty e-mail.
Proszenie użytkowników o podanie hasła do ich adresu e-mail i przechowywanie go – nawet zaszyfrowanego – jest najbardziej ryzykownym wzorcem w integracji poczty e-mail. Sprawia to, że Twoja baza danych staje się cennym celem. Jeśli atakujący uzyska dostęp do Twojego magazynu poświadczeń, uzyska bezpośredni dostęp do skrzynki odbiorczej każdego użytkownika. Poza ryzykiem bezpieczeństwa, Google i Microsoft jednoznacznie zabraniają dostępu do kont Gmail i Outlook poprzez hasło dla aplikacji stron trzecich. IMAP z hasłem jest akceptowalny tylko w przypadku poczt serwerów hostowanych lokalnie lub starszych, gdzie OAuth jest rzeczywiście niedostępny.
Żądanie https://mail.google.com/ (pełny dostęp do Gmail) kiedy potrzebujesz tylko odczytać folder wysłanych użytkownika jest anty-wzorem zakresu. Szerokie zakresy zwiększają promień rażenia w przypadku przejęcia tokena i podważają zaufanie użytkowników podczas ekranu zgody OAuth - użytkownicy, którzy widzą "odczytaj, napisz, wyślij i trwale usuń całą swoją pocztę", słusznie się wahają. Zarówno Google, jak i Microsoft flagują obecnie niepotrzebne użycie zakresów podczas przeglądu aplikacji.
Tokeny dostępu OAuth są zaprojektowane jako krótkotrwałe – zazwyczaj obowiązują przez godzinę w przypadku Gmaila i Outlooka. Tokeny odświeżania mogą być ważne przez miesiące lub nieokreślony czas. Jeśli przechowujesz tokeny odświeżania bez strategii rotacji, wyciekający token odświeżania zapewnia długoterminowy dostęp do skrzynki pocztowej użytkownika. Niektóre integracje buforują również tokeny dostępu długo po ich wygaśnięciu i nie obsługują zdarzeń odwołania (gdy użytkownik usunie Twoją aplikację z ustawień swojego konta Google lub Microsoft).
Dzienniki aplikacji są często mniej chronione niż główne bazy danych, przechowywane dłużej i replikowane do wielu systemów (agregatory logów, usługi monitorujące, narzędzia do śledzenia błędów). Rejestrowanie pełnych treści wiadomości e-mail, nagłówków zawierających dane osobowe lub list odbiorców stwarza znaczące ryzyko związane z RODO: przetwarzane są dane osobowe w kontekście, na który użytkownik nigdy nie wyraził zgody i którego nie można zweryfikować. Dzienniki błędów zawierające surowe odpowiedzi API mogą mimowolnie przechwytywać całe wątki e-maili.
Zgodność z RODO w integrowaniu API poczty elektronicznej
Dane dotyczące poczty elektronicznej należą do najbardziej wrażliwych kategorii danych osobowych w świetle RODO. Gdy Twoja aplikacja uzyskuje dostęp do skrzynki odbiorczej użytkownika przez API, stajesz się procesorem danych. Tworzy to konkretne zobowiązania prawne dotyczące rezydencji, zgody i prawa do usunięcia, które Twoja architektura API poczty elektronicznej musi wspierać.
Dane osobowe z UE muszą pozostać w UE lub w krajach posiadających decyzję o adekwatności. Twoja infrastruktura API poczty e-mail musi oferować punkty końcowe hostowane w UE.
Użytkownicy muszą wyraźnie autoryzować dostęp do swojej skrzynki pocztowej. Ekran zgody OAuth musi jasno określać, jakie dane będą dostępne i w jakim celu.
W przypadku żądania usunięcia lub odłączenia konta przez użytkownika, wszystkie powiązane tokeny, dane tymczasowe i dane osobowe muszą zostać usunięte w terminach określonych przez RODO.
Rezydencja danych
Zgodnie z art. 44 RODO, przekazywanie danych osobowych poza Europejski Obszar Gospodarczy wymaga wydania decyzji stwierdzającej odpowiedni stopień ochrony, zastosowania standardowych klauzul umownych (SCC) lub innego zgodnego z prawem mechanizmu. W przypadku integracji API pocztowych obsługujących użytkowników z UE infrastruktura przechowująca tokeny OAuth, przetwarzająca metadane poczty lub buforująca treść wiadomości musi być zlokalizowana w UE. Wybór dostawcy API bez opcji rezydencji danych w UE zmusza do polegania na SCC i dodatkowych obciążeń związanych z zgodnością. W przypadku zastosowań medycznych lub finansowych, gdzie obowiązują wymogi zbliżone do HIPAA, rezydencja danych staje się tym bardziej krytyczna.
Dostawca Państwa API do poczty e-mail jest podpowiernikiem zgodnie z RODO. Musisz mieć z nim umowę powierzenia przetwarzania danych (DPA), a jego infrastruktura musi obsługiwać rezydencję danych w UE dla wszelkich danych użytkowników z UE, które przetwarza w Państwa imieniu.
Przepływ zgody użytkownika
Przepływ autoryzacji OAuth stanowi techniczne wdrożenie zgody RODO na dostęp do poczty e-mail – ale tylko wtedy, gdy jest prawidłowo zaprojektowany. Ekran zgody musi jasno opisywać, do czego aplikacja uzyska dostęp, w prostym języku. Żądanie zakresów wykraczających poza to, co opisano w Twojej polityce prywatności, tworzy lukę w przestrzeganiu przepisów. Użytkownicy muszą również mieć możliwość ukończenia tego przepływu bez przymusu: połączenie ich konta e-mail nie może być wymogiem do uzyskania dostępu do Twojej podstawowej usługi, chyba że dostęp do poczty e-mail stanowi samą usługę.
Prawo do usunięcia - odłączenie konta
Artykuł 17 RODO przyznaje użytkownikom prawo do usunięcia danych. W kontekście integracji poczty elektronicznej oznacza to, że Twoja aplikacja musi być w stanie natychmiast i całkowicie usunąć wszelkie ślady dostępu użytkownika do poczty elektronicznej na żądanie. Nie chodzi tu tylko o usunięcie tokena OAuth – obejmuje to każdy artefakt utworzony w całym okresie trwania integracji.
Jak Unipile zabezpiecza API e-mail
Bezpieczeństwo nie jest funkcją, którą dodaje się do Unipile – jest ono domyślnym zachowaniem platformy. Unipile został zaprojektowany specjalnie do dostarczania bezpiecznego API poczty e-mail, w którym uwierzytelnianie, bezpieczeństwo danych poczty e-mail i kontrolki zgodności są wbudowane domyślnie – nie dodane później. Każda decyzja architektoniczna dotycząca sposobu, w jaki Unipile łączy się z kontami Gmail, Outlook i IMAP, jest podejmowana z myślą o bezpieczeństwie i prywatności użytkowników końcowych jako głównym ograniczeniu.
Unipile łączy się z Gmail przez Google OAuth 2.0 i do Outlooka i Microsoft 365 przez Microsoft OAuth 2.0. Twoi użytkownicy uwierzytelniają się bezpośrednio za pomocą oficjalnego ekranu zgody dostawcy. Żadne hasło nigdy nie przechodzi przez infrastrukturę Unipile. W przypadku kont IMAP, gdzie OAuth jest niedostępny, dane uwierzytelniające są szyfrowane w spoczynku za pomocą AES-256 i nigdy nie są ujawniane w żadnej odpowiedzi API – w tym w Przewodnik po interfejsie API IMAP szczegółowo omawia tę architekturę.
Unipile żąda najwęższych zakresów OAuth niezbędnych dla funkcji, które udostępnia Twoja aplikacja SaaS. Jeśli Twoja integracja jedynie odczytuje e-maile w celu uzupełnienia kanału aktywności CRM, Unipile żąda zakresów tylko do odczytu. Zakres wysyłania jest dodawany tylko wtedy, gdy Twoja implementacja wyraźnie tego wymaga. Zmniejsza to zakres uszkodzeń w przypadku problemów z poświadczeniami i sprawia, że ekran zgody OAuth Twojej aplikacji jest prosty do zaakceptowania przez użytkowników końcowych.
Dla zespołów SaaS obsługujących klientów z UE, Unipile oferuje opcje infrastruktury hostowanej w UE. Tokeny OAuth, metadane powiązanych kont oraz wszelkie dane e-mail przetwarzane tymczasowo pozostają w jurysdykcji UE. Pozwala to na utrzymanie przejrzystej dokumentacji przetwarzania danych zgodnie z RODO oraz na zawarcie Umowy o powierzenie przetwarzania danych z Unipile jako własnym podpowiernikiem - wymóg prawny zgodnie z artykułem 28 RODO dla każdego podmiotu przetwarzającego dane osobowe z UE w Twoim imieniu.
Unipile udostępnia punkt końcowy DELETE dla połączonych kont. Wywołanie go natychmiast unieważnia token OAuth na poziomie dostawcy, usuwa wszystkie powiązane metadane z infrastruktury Unipile i anuluje wszelkie aktywne subskrypcje webhook. Daje to czystą, jednokrotną ścieżkę API do realizacji żądań związanych z prawem do usunięcia danych zgodnie z RODO dotyczących dostępu do poczty e-mail – bez konieczności ręcznego czyszczenia danych w wielu panelach dostawców.
Przeczytaj pełne odniesienie do API - przepływy uwierzytelniania, zarządzanie tokenami i bezpieczeństwo webhooków.
Certyfikaty zgodności
Unipile jest niezależnie audytowany i certyfikowany zgodnie z trzema ramami zgodności, które są najbardziej istotne dla bezpiecznych integracji API poczty e-mail: operacje bezpieczeństwa, ochrona danych i dostęp do API Google.
Audytowane przez niezależną stronę trzecią. Obejmuje kryteria usług zaufania dotyczące bezpieczeństwa, dostępności i poufności w całej infrastrukturze Unipile's.
Pełna zgodność z przepisami UE dotyczącymi ochrony danych. Unipile działa jako Podmiot Przetwarzający dane. Wszystkie dane są hostowane wyłącznie w UE. Umowa powierzenia przetwarzania danych dostępna na życzenie.
Ocena bezpieczeństwa aplikacji Google Cloud. Waliduje kontrole bezpieczeństwa aplikacji uzyskujących dostęp do danych użytkowników Google, w tym zakresy OAuth Gmail.
Kiedy tworzysz na Unipile, Twoja bezpieczna integracja poczty e-mail czerpie korzyści z tych samych kontroli bezpieczeństwa, które przeszły te audyty. Jest to szczególnie istotne dla CASA Tier II: aplikacje zbudowane na bazie certyfikowanego przez CASA bezpiecznego API poczty e-mail mogą utrzymać swój własny status zgodności w całym łańcuchu integracji — bez oddzielnego audytu warstwy poczty e-mail.
Lista kontrolna bezpieczeństwa dla integracji z API poczty e-mail
Przed wysłaniem jakiejkolwiek integracji API poczty elektronicznej do produkcji, skorzystaj z tej listy kontrolnej. Wszystkie pozycje muszą zostać zweryfikowane, zanim integracja może być uznana za gotową do produkcji pod względem bezpieczeństwa.
OAuth 2.0, minimalne zakresy, rezydencja danych w UE, natychmiastowe rozłączenie konta - wszystko zawarte w jednym bezpiecznym API e-mail. Połącz Gmail, Outlook i IMAP z szyfrowanym dostępem do poczty e-mail i bez przechowywania haseł.
Bezpieczne API e-mail - FAQ
Najczęściej zadawane pytania dotyczące bezpieczeństwa API poczty e-mail, OAuth i zgodności
IMAP może być bezpieczny, ale wszystko zależy od jego implementacji. Protokół sam w sobie przesyła dane przez TLS po odpowiednim skonfigurowaniu, więc warstwa transmisji nie stanowi problemu. Ryzyko tkwi w sposobie obsługi poświadczeń. IMAP wymaga nazwy użytkownika i hasła – w przeciwieństwie do Gmaila i Outlooka, które obsługują OAuth 2.0, IMAP nie posiada standardu delegowanego uwierzytelniania. Oznacza to, że aplikacja musi przechowywać lub pobierać hasło użytkownika za każdym razem, gdy się łączy. Jest to możliwe do zarządzania, jeśli poświadczenia są szyfrowane w spoczynku za pomocą AES-256, dostęp do magazynu poświadczeń jest ściśle ograniczony, a hasła nigdy nie są logowane ani udostępniane w odpowiedziach API. W przypadku Gmaila i Outlooka zawsze preferuj OAuth 2.0 zamiast IMAP z hasłem – obaj dostawcy wymagają go dla aplikacji zewnętrznych. IMAP z hasłem nadaje się tylko do samodzielnie hostowanych serwerów pocztowych lub starszych środowisk korporacyjnych, gdzie OAuth jest niedostępny. Więcej informacji można znaleźć w Przewodnik po interfejsie API IMAP.
Zgodność z HIPAA dla integracji API poczty e-mail jest osiągalna, ale wymaga starannej architektury. HIPAA nie certyfikuje dostawców poczty e-mail - wymaga raczej, aby każdy system obsługujący chronione informacje zdrowotne (PHI) wdrażał określone zabezpieczenia techniczne: szyfrowanie w transporcie i w spoczynku, kontrole audytu, kontrole dostępu i automatyczne wylogowywanie dla nieaktywnych sesji. W przypadku interfejsu API poczty e-mail oznacza to: korzystanie z OAuth 2.0, aby nie przechowywać żadnych haseł, zapewnienie, że tokeny i wszelkie buforowane metadane są szyfrowane w spoczynku, nigdy nie rejestrowanie treści wiadomości e-mail, które mogą zawierać PHI, oraz posiadanie umowy Business Associate Agreement (BAA) z dostawcą API. Gmail i Outlook oferują konfiguracje kwalifikujące się do HIPAA odpowiednio w ramach planów Google Workspace i Microsoft 365 Business, z podpisaną umową BAA od dostawcy. Warstwa API poczty e-mail musi również podpisać z Tobą umowę BAA, jeśli przetwarza lub przesyła PHI w Twoim imieniu. Z praktycznego punktu widzenia najbezpieczniejszą ścieżką HIPAA jest traktowanie treści wiadomości e-mail jako przejściowych - odczytywanie, przetwarzanie, wyświetlanie - ale nigdy nie przechowywanie treści ani załączników we własnej bazie danych.
Odebranie dostępu do poczty użytkownika obejmuje dwa odrębne działania, które muszą zostać wykonane. Najpierw unieważnij token na poziomie dostawcy. Dla Gmail, wywołaj punkt końcowy odwoływania tokenów Google (https://oauth2.googleapis.com/revoke). W przypadku Outlooka wywołaj punkt końcowy unieważniania firmy Microsoft lub usuń aplikację z konta użytkownika Microsoft. Samo usunięcie tokenu z bazy danych nie wystarczy – token pozostaje ważny u dostawcy do czasu jego jawnego unieważnienia. Po drugie, usuń wszystkie dane lokalne. Usuń token odświeżania, wszelkie buforowane tokeny dostępu, wszelkie przechowywane metadane poczty e-mail dla tego połączonego konta, subskrypcje webhooków i sam rekord połączonego konta. Z Unipile, jedno USUŃ /konta/{id} wywołanie wykonuje oba kroki - odwołuje token u dostawcy i jednocześnie usuwa wszystkie powiązane dane z infrastruktury Unipile.
Bezpieczeństwo poczty e-mail zazwyczaj odnosi się do ochrony samej komunikacji e-mail – filtrowania spamu, wykrywania phishingu, uwierzytelniania DKIM/SPF/DMARC oraz szyfrowania wiadomości podczas przesyłania między serwerami pocztowymi. Bezpieczeństwo API poczty e-mail to zupełnie inna warstwa: dotyczy tego, jak aplikacja strony trzeciej uzyskuje programowy dostęp do skrzynki pocztowej użytkownika, jakie dane w wyniku tego przetwarza i jak chroni ten dostęp. Można mieć doskonałe zabezpieczenia poczty e-mail (skonfigurowany DMARC, wymuszony TLS między serwerami), a jednocześnie mieć słabe zabezpieczenia API poczty e-mail (hasła przechowywane w postaci zwykłego tekstu, zbyt szerokie zakresy OAuth). Oba aspekty są ważne niezależnie. Artykuł ten koncentruje się na warstwie bezpieczeństwa API – decyzjach architektonicznych podejmowanych przez zespół programistyczny podczas integracji z Gmail, Outlook lub IMAP za pośrednictwem API.
Unipile nie przechowuje trwale treści wiadomości e-mail. Kiedy twoja aplikacja wywołuje API Unipile w celu pobrania wiadomości e-mail, Unipile pobiera dane z dostawcy (Gmail, Outlook lub serwer IMAP) w czasie rzeczywistym i zwraca je do twojej aplikacji. Treści wiadomości e-mail i załączniki nie są buforowane ani przechowywane w infrastrukturze Unipile poza cyklem życia żądania. Unipile przechowuje token OAuth (szyfrowany podczas przechowywania) i podstawowe metadane połączonego konta potrzebne do utrzymania połączenia - typ dostawcy, identyfikator konta i stan połączenia. Taka architektura oznacza, że treść wiadomości e-mail pozostaje między twoją aplikacją a dostawcą, a Unipile działa jako bezpieczny pośrednik, a nie jako magazyn danych. Pełne szczegóły dotyczące sposobu, w jaki Unipile obsługuje dane, można znaleźć w sekcji dokumentacja deweloperska i poproś zespół Unipile o DPA.
OAuth 2.0 poprawia bezpieczeństwo integracji poczty e-mail na cztery konkretne sposoby. Brak ujawnienia poświadczeń: hasło użytkownika nigdy nie opuszcza serwera dostawcy - Twoja aplikacja zawsze otrzymuje jedynie krótkotrwały token dostępu. Uprawnienia granularne Zakresy OAuth pozwalają na żądanie dokładnie takiej ilości dostępu, jakiej potrzebujesz (tylko do odczytu, tylko do wysyłania), zamiast pełnej kontroli nad skrzynką pocztową. Odwołalność Użytkownik może w dowolnym momencie usunąć dostęp aplikacji z ustawień swojego konta Google lub Microsoft, bez konieczności zmiany hasła, a token staje się natychmiast nieważny. Krótkotrwałe tokeny: tokeny dostępu wygasają (zazwyczaj po godzinie), ograniczając zakres narażenia w przypadku kompromitacji tokena. Te właściwości sprawiają, że OAuth 2.0 jest jedynym akceptowalnym mechanizmem uwierzytelniania dla integracji Gmail i Outlook w produkcyjnych aplikacjach SaaS. Dowiedz się, jak go zaimplementować z Google OAuth 2.0 oraz Microsoft OAuth 2.0.
Masz jeszcze jakieś pytania? Nasz zespół służy pomocą.
PL 
EN 
FR 
ES 
DE 
IT 
BR 
NL 
TR