Biztonságos automatizálás: külön alkalmazás, külön hitelesítő adat, csak a szükséges postafiókok

Egy automatizmus nem attól biztonságos, hogy jól működik. Attól is, hogy csak azt olvashatja és módosíthatja, amire ténylegesen szüksége van.

Egy saját operatív folyamatban az érkező e-mailekből készítünk strukturált feladatjelölteket. Ehhez bizonyos levelek törzsét is fel kell dolgozni. A legegyszerűbb technikai út az lett volna, hogy a meglévő integráció kap egy széles Microsoft Graph Mail.Read jogosultságot.

Nem ezt választottuk.

A döntés: külön alkalmazás az elkülönített feladathoz

A működő modell:

• külön Entra-alkalmazás az e-mailek olvasásához;
• külön OAuth-hitelesítő adat;
• alkalmazásszintű (app-only) hozzáférés, mert a folyamatnak emberi bejelentkezés nélkül kell futnia;
• Exchange Application RBAC hatókör csak a kijelölt postafiókokra;
• csak olvasási jogosultság;
• nincs levélküldés, törlés vagy módosítás.

A tervezési elv egyszerű:

ne egy meglévő automatizmus jogosultságait bővítsük addig, amíg szinte mindent elér. Érdemes különválasztani a feladatokat és a hozzájuk tartozó hitelesítő adatokat.

Miért nem elég a Mail.ReadBasic?

Ha csak feladó, tárgy, időpont és hasonló metaadat kell, a teljes levéltörzs olvasása indokolatlan.

Nálunk azonban a következő információk gyakran a levél törzsében szerepelnek:

• fizetési vagy lejárati részlet;
• konkrét hibaleírás;
• biztonsági figyelmeztetés;
• domain- vagy tárhelyinformáció;
• ügyfél által leírt következő teendő.

A Microsoft dokumentációja szerint a Mail.ReadBasic többek között a levél törzséhez, előnézetéhez és mellékleteihez sem ad hozzáférést. Emiatt ehhez a feladathoz Mail.Read jogosultságra volt szükség.

Itt viszont jön a második kérdés: mely postafiókokra?

Szűk jogosultsági kör Exchange Application RBAC-kal

Az Exchange Online Application RBAC lehetővé teszi, hogy az alkalmazás jogosultsága ne feltétlenül terjedjen ki a teljes szervezetre.

Ahelyett, hogy az alkalmazás minden postafiókot olvashatna, külön meghatározható, mely postafiókokra terjedjen ki a jogosultsága.

A nálunk validált minta logikája:

külön Entra-alkalmazás → Application Mail.Read → Exchange Application RBAC → csak a szükséges postafiókok

Ez nem teszi kockázatmentessé az alkalmazásszintű jogosultságot. A kliens hitelesítő adata továbbra is érzékeny titok, amelynek megszerzése hozzáférést adhat az engedélyezett postafiókokhoz.

Viszont egy esetleges kompromittálás hatóköre lényegesen kisebb, mint teljes szervezetre kiterjedő olvasási jog esetén.

Fontos csapda: a széles és a szűkített jog összeadódhat

A Microsoft dokumentációjának egyik fontos részlete, hogy az Exchange Application RBAC és az Entra ID-ban kiadott alkalmazásjogosultságok hatása összeadódhat.

Gyakorlati következmény:

ha az alkalmazás megkapja a szűk Exchange RBAC Mail.Read jogosultságot, de mellette megmarad egy szervezetszintű Graph Mail.Read alkalmazásjogosultság is, akkor a szélesebb jogosultság felülírhatja a szűkítés célját.

Ezért a legkisebb szükséges jogosultság elve nem csak azt jelenti, hogy létrehoztunk egy szűk hatókört. Azt is ellenőrizni kell, hogy nincs mellette másik, szélesebb engedélyezési út.

A csak olvasási jogosultság maradjon valóban csak olvasási

Az e-mail-feldolgozó folyamatnak nem volt szüksége ezekre:

• Mail.Send;
• Mail.ReadWrite;
• törlés;
• archiválás;
• mappamozgatás;
• read/unread állapot módosítása;
• automatikus válasz.

Ezért ezeket nem is kapta meg.

Az ilyen döntés később is hasznos. Ha a folyamat logikája hibás lesz, egy rossz klasszifikáció legfeljebb rossz feladatjelöltet hozhat létre; nem tud közben leveleket törölni vagy elküldeni.

A titkos hitelesítő adat ne legyen a folyamat része

A hitelesítő adatok kezelésének másik alapelve:

• a kliens titkos kulcsa ne kerüljön exportált folyamatleírásba;
• a hozzáférési token ne kerüljön naplóba vagy tudásbázisba;
• a levél törzse ne váljon hibakeresési adatként tartós IKB-tartalommá;
• a konfiguráció és a titkos hitelesítő adatok életciklusa legyen szétválasztva.

Egy automatizmus exportja akkor is kerülhet verziókezelésbe, ha maga a hitelesítő adat nem.

Kézi ellenőrzés mint biztonsági szelep

Nem minden e-mailből kell automatikusan feladat.

A bizonytalan találatoknál biztonságosabb folyamat:

beérkező levél → osztályozás → bizonytalan találatnál kézi ellenőrzés → egyértelmű találatnál további feldolgozás

Ez nem csak AI- vagy szabályalapú osztályozásnál hasznos. Bármilyen automatizálásnál csökkenti annak kockázatát, hogy egy hibás heurisztika közvetlen üzleti műveletté váljon.

Öt kérdés új automatizmus előtt

1. Kell-e alkalmazásjogosultság emberi bejelentkezés nélkül (app-only), vagy használható delegált hozzáférés?
2. Kell-e teljes tartalom, vagy elég metaadat?
3. Mely erőforrásokhoz kell ténylegesen hozzáférni?
4. Kell-e írási jog, vagy elég a csak olvasási működés?
5. Van-e másik jogosultság vagy hitelesítő adat, amely a tervezett hatókört megkerüli?

A jó automatizmus nemcsak időt takarít meg: az is dokumentált, hogy mire jogosult, és mire nem.

Források

• Microsoft Learn: Role Based Access Control for Applications in Exchange Online
• Microsoft Learn: Microsoft Graph permissions overview
• Microsoft Learn: Best practices for working with Microsoft Graph permissions