Automatizálás least privilege szerint: külön app, külön credential, csak a szükséges mailboxok

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 workflow-ban 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 app egy külön felelősséghez

A működő modell:

• külön Entra alkalmazás az e-mail olvasási funkcióhoz;
• külön OAuth credential;
• app-only hozzáférés csak azért, mert háttérfolyamatként emberi bejelentkezés nélkül kell futnia;
• Exchange Application RBAC scope csak a kijelölt mailboxokra;
• 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 már meglévő automatizmus jogosultságait bővítsd addig, amíg az „mindent tud”. Válaszd szét a felelősségeket és a credentialeket.

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

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

Nálunk azonban a következő információk gyakran a body-ban 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 nem ad hozzáférést többek között a levél body-jához, preview-jához és mellékleteihez. Emiatt a funkcionális igényhez Mail.Read kellett.

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

Resource scope Exchange Application RBAC-kal

Az Exchange Online Application RBAC célja, hogy alkalmazásjogosultságot ne feltétlenül a teljes szervezetre adjunk.

Ahelyett, hogy az alkalmazás minden postafiókot olvashatna, egy dedikált resource scope határozhatja meg, mely mailboxok vannak a jogosultságon belül.

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

külön Entra app → Application Mail.Read → Exchange Application RBAC → csak a szükséges mailboxok

Ez nem teszi kockázatmentessé az app-only jogosultságot. A client credential továbbra is érzékeny secret, és a kompromittálása a megadott scope-on belül hozzáférést adhat.

Viszont a blast radius lényegesen kisebb, mint tenant-wide olvasási jog esetén.

Fontos csapda: a széles és a scoped jog összeadódhat

Az egyik legfontosabb Microsoft-dokumentációs részlet, hogy az Exchange Application RBAC és az Entra ID-ban kiadott application permissionök hatása unionként érvényesülhet.

Gyakorlati következmény:

ha az appnak megadod a szűk Exchange RBAC Mail.Read scope-ot, de mellette aktívan hagysz egy szervezetszintű Graph Mail.Read application permissiont, akkor a széles jogosultság alááshatja a scope célját.

Ezért a least privilege nem csak azt jelenti, hogy létrehoztunk egy szűk scope-ot. Azt is ellenőrizni kell, hogy nincs mellette másik, szélesebb engedélyezési út.

Read-only tényleg read-only legyen

Az e-mail feldolgozó workflow-nak 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 workflow 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 secret ne legyen a workflow része

A credential-kezelés másik alapelve:

• client secret ne kerüljön exportált workflow JSON-ba;
• access token ne kerüljön logba vagy tudásbázisba;
• mailbox body ne váljon debug-adatként tartós IKB-tartalommá;
• a konfiguráció és a secret lifecycle legyen szétválasztva.

Egy automatizmus exportja akkor is kerülhet verziókezelésbe, ha a credential maga nem.

Kézi review mint biztonsági szelep

Nem minden e-mailből kell automatikusan feladat.

A bizonytalan találatoknál jobb minta:

Inbox → klasszifikáció → bizonytalan: review → magas biztonságú találat: következő feldolgozási lépés

Ez nem csak AI- vagy szabályalapú klasszifikációná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 app-only jogosultság, vagy használható delegated access?
2. Kell-e teljes tartalom, vagy elég metadata?
3. Mely erőforrásokra kell ténylegesen hozzáférni?
4. Kell-e írási jog, vagy elég a read-only működés?
5. Van-e másik permission vagy credential, amely a tervezett scope-ot megkerüli?

A jó automatizmus nemcsak időt takarít meg. Korlátai is dokumentáltak.

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