Az Azure RMS működése Technikai részletek

Az Azure RMS működésével kapcsolatban fontos megérteni, hogy az Azure Information Protection adatvédelmi szolgáltatása nem látja vagy tárolja az adatokat a védelmi folyamat részeként. Az Ön által védett információkat a rendszer soha nem küldi el vagy tárolja az Azure-ban, kivéve, ha kifejezetten az Azure-ban tárolja őket, vagy nem használ egy másik felhőszolgáltatást, amely az Azure-ban tárolja őket. Az Azure RMS egyszerűen olvashatatlanná teszi a dokumentum adatait a jogosult felhasználókon és szolgáltatásokon kívül:

• Az adatok titkosítása az alkalmazás szintjén történik, és tartalmaz egy szabályzatot, amely meghatározza a dokumentum engedélyezett használatát.

• Ha egy védett dokumentumot egy megbízható felhasználó használ, vagy egy jogosult szolgáltatás dolgozza fel, a rendszer visszafejti a dokumentum adatait, és kikényszeríti a szabályzatban meghatározott jogosultságokat.

Magas szinten az alábbi képen láthatja, hogyan működik ez a folyamat. A titkos képletet tartalmazó dokumentum védett, majd egy jogosult felhasználó vagy szolgáltatás sikeresen megnyitja. A dokumentumot tartalomkulcs védi (a képen látható zöld kulcs). Minden dokumentumhoz egyedi, és a fájlfejlécbe kerül, ahol az Azure Information Protection-bérlő gyökérkulcsa (a képen látható piros kulcs) védi. A bérlőkulcsot létrehozhatja és felügyelheti a Microsoft, vagy létrehozhatja és kezelheti a saját bérlőkulcsát.

A védelmi folyamat során, amikor az Azure RMS titkosítja és visszafejti, engedélyezi és érvényesíti a korlátozásokat, a titkos képlet soha nem lesz elküldve az Azure-ba.

A történések részletes leírását az Azure RMS működéséről szóló útmutatóban találja: Az első használat, a tartalomvédelem és a tartalomfelhasználás szakasza ebben a cikkben.

Az Azure RMS által használt algoritmusokkal és kulcshosszokkal kapcsolatos technikai részletekért tekintse meg a következő szakaszt.

Az Azure RMS által használt titkosítási vezérlők: Algoritmusok és kulcshosszok

Még ha nem is kell részletesen megtudnia, hogyan működik ez a technológia, a rendszer megkérdezheti az általa használt titkosítási vezérlőkről. Például annak megerősítéséhez, hogy a biztonsági védelem iparági szabvány.

Titkosítási vezérlők	Használat az Azure RMS-ben
Algoritmus: AES Kulcshossz: 128 bit és 256 bit [1]	Tartalomvédelem
Algoritmus: RSA Kulcs hossza: 2048 bit [2]	Kulcsvédelem
SHA-256	Tanúsítvány aláírása

1. lábjegyzet

Az Azure Information Protection-ügyfél a következő esetekben 256 bitet használ:

• Általános védelem (.pfile).

• A PDF-dokumentumok natív védelme, ha a dokumentumot a PDF-titkosítás ISO szabványa védi, vagy az eredményül kapott védett dokumentum .ppdf fájlnévkiterjesztéssel rendelkezik.

• Szöveg- vagy képfájlok (például .ptxt vagy .pjpg) natív védelme.

Lábjegyzet 2

A 2048 bites kulcshossz a Azure Tartalomvédelmi szolgáltatások szolgáltatás aktiválásakor. Az 1024 bit támogatott a következő választható forgatókönyvekben:

• Helyszíni migrálás során, ha az AD RMS-fürt 1. titkosítási módban fut.

• A migrálás előtt a helyszínen létrehozott archivált kulcsok esetében, hogy a korábban AD RMS által védett tartalmakat a migrálást követően a Azure Tartalomvédelmi szolgáltatások szolgáltatás továbbra is megnyithassa.

Az Azure RMS titkosítási kulcsainak tárolása és védelme

Az Azure RMS által védett minden dokumentumhoz vagy e-mailhez az Azure RMS létrehoz egy AES-kulcsot (a "tartalomkulcsot"), és a kulcs beágyazva van a dokumentumba, és a dokumentum kiadásain keresztül megmarad.

A tartalomkulcs a dokumentum szabályzatának részeként a szervezet RSA-kulcsával (az "Azure Information Protection bérlőkulcsával") van védve, és a szabályzatot a dokumentum szerzője is aláírja. Ez a bérlőkulcs a szervezet Azure Tartalomvédelmi szolgáltatások szolgáltatása által védett összes dokumentumra és e-mailre jellemző, és ezt a kulcsot csak akkor módosíthatja egy Azure Information Protection-rendszergazda, ha a szervezet ügyfél által felügyelt bérlőkulcsot használ (más néven "saját kulcs használata" vagy BYOK).

Ez a bérlőkulcs védett a Microsoft online szolgáltatások, szigorúan ellenőrzött környezetben és szoros figyelés alatt. Ha ügyfél által felügyelt bérlőkulcsot (BYOK) használ, ezt a biztonságot a csúcskategóriás hardveres biztonsági modulok (HSM-ek) tömbje növeli az egyes Azure-régiókban anélkül, hogy a kulcsok bármilyen körülmények között kinyerhetők, exportálhatók vagy megoszthatók. A bérlőkulcsról és a BYOK-ról további információt az Azure Information Protection-bérlőkulcs tervezésével és implementálásával kapcsolatban talál.

A Windows-eszközre küldött licencek és tanúsítványok az ügyfél eszköz titkos kulcsával vannak védve, amely akkor jön létre, amikor az eszközön egy felhasználó először használja az Azure RMS-t. Ez a titkos kulcs viszont DPAPI-val van védve az ügyfélen, amely a felhasználó jelszavából származtatott kulccsal védi ezeket a titkos kulcsokat. Mobileszközökön a kulcsokat csak egyszer használja a rendszer, ezért mivel az ügyfelek nem tárolják őket, ezeket a kulcsokat nem kell védeni az eszközön.

Útmutató az Azure RMS működéséhez: Első használat, tartalomvédelem, tartalomhasználat

Az Azure RMS működésének részletesebb megismeréséhez tekintsük át az Azure Tartalomvédelmi szolgáltatások szolgáltatás aktiválása utáni tipikus folyamatot, és amikor egy felhasználó először használja a Rights Management szolgáltatást a Windows-számítógépén (ez a folyamat más néven a felhasználói környezet inicializálása vagy a rendszerindítás), védi a tartalmat (dokumentumot vagy e-mailt), majd felhasználja (megnyit és használ) olyan tartalmat, amelyet valaki más védett.

A felhasználói környezet inicializálása után a felhasználó megvédheti a dokumentumokat, vagy használhat védett dokumentumokat a számítógépen.

Megjegyzés:

Ha ez a felhasználó másik Windows-számítógépre költözik, vagy egy másik felhasználó ugyanazt a Windows-számítógépet használja, az inicializálási folyamat ismétlődik.

A felhasználói környezet inicializálása

Ahhoz, hogy egy felhasználó védett tartalmakat védhet vagy védett tartalmakat használjon windowsos számítógépen, a felhasználói környezetet elő kell készíteni az eszközön. Ez egy egyszeri folyamat, amely automatikusan, felhasználói beavatkozás nélkül történik, amikor egy felhasználó védett tartalmat próbál védeni vagy felhasználni:

Mi történik az 1. lépésben: A számítógépen lévő RMS-ügyfél először csatlakozik a Azure Tartalomvédelmi szolgáltatások szolgáltatáshoz, és a Microsoft Entra-fiókjával hitelesíti a felhasználót.

Ha a felhasználó fiókja össze van vonva a Microsoft Entra-azonosítóval, ez a hitelesítés automatikus, és a rendszer nem kéri a felhasználótól a hitelesítő adatokat.

Mi történik a 2. lépésben: A felhasználó hitelesítése után a rendszer automatikusan átirányítja a kapcsolatot a szervezet Azure Information Protection-bérlőjére, amely tanúsítványokat ad ki, amelyek lehetővé teszik a felhasználó számára a hitelesítést a Azure Tartalomvédelmi szolgáltatások szolgáltatásban a védett tartalom felhasználása és a tartalom offline védelme érdekében.

Ezen tanúsítványok egyike a rights account tanúsítvány, amelyet gyakran rövidítünk RAC-nek. Ez a tanúsítvány hitelesíti a felhasználót a Microsoft Entra-azonosítón, és 31 napig érvényes. Az RMS-ügyfél automatikusan megújítja a tanúsítványt, feltéve, hogy a felhasználói fiók továbbra is a Microsoft Entra-azonosítóban van, és a fiók engedélyezve van. Ezt a tanúsítványt a rendszergazda nem konfigurálhatja.

A tanúsítvány egy példánya az Azure-ban van tárolva, így ha a felhasználó másik eszközre költözik, a tanúsítványokat ugyanazokkal a kulcsokkal hozza létre.

Tartalomvédelem

Amikor egy felhasználó védi a dokumentumokat, az RMS-ügyfél a következő műveleteket hajtja végre egy nem védett dokumentumon:

Mi történik az 1. lépésben: Az RMS-ügyfél létrehoz egy véletlenszerű kulcsot (a tartalomkulcsot), és ezzel a kulccsal titkosítja a dokumentumot az AES szimmetrikus titkosítási algoritmusával.

Mi történik a 2. lépésben: Az RMS-ügyfél ezután létrehoz egy tanúsítványt, amely tartalmazza a dokumentumra vonatkozó szabályzatot, amely tartalmazza a felhasználók vagy csoportok használati jogosultságait , valamint egyéb korlátozásokat, például a lejárati dátumot. Ezek a beállítások meghatározhatók olyan sablonban, amelyet a rendszergazda korábban konfigurált, vagy a tartalom védelmekor adott meg (más néven alkalmi szabályzat).

A kijelölt felhasználók és csoportok azonosítására használt fő Microsoft Entra attribútum a Microsoft Entra ProxyAddresses attribútum, amely egy felhasználó vagy csoport összes e-mail-címét tárolja. Ha azonban egy felhasználói fiók nem tartalmaz értékeket az AD ProxyAddresses attribútumban, a rendszer ehelyett a felhasználó UserPrincipalName értékét használja.

Az RMS-ügyfél ezután a felhasználói környezet inicializálásakor beszerzett szervezeti kulcsot használja, és ezzel a kulccsal titkosítja a szabályzatot és a szimmetrikus tartalomkulcsot. Az RMS-ügyfél a felhasználói környezet inicializálásakor beszerzett felhasználói tanúsítvánnyal is aláírja a szabályzatot.

Mi történik a 3. lépésben: Végül az RMS-ügyfél beágyazza a szabályzatot egy fájlba, amely a korábban titkosított dokumentum törzsét tartalmazza, amely egy védett dokumentumot tartalmaz.

Ez a dokumentum bárhol tárolható vagy bármely módszerrel megosztható, és a szabályzat mindig a titkosított dokumentummal marad.

Tartalomhasználat

Amikor egy felhasználó védett dokumentumot szeretne használni, az RMS-ügyfél a Azure Tartalomvédelmi szolgáltatások szolgáltatáshoz való hozzáférés kérésével kezdődik:

Mi történik az 1. lépésben: A hitelesített felhasználó elküldi a dokumentumszabályzatot és a felhasználó tanúsítványait a Azure Tartalomvédelmi szolgáltatások szolgáltatásnak. A szolgáltatás visszafejti és kiértékeli a szabályzatot, és létrehozza a felhasználó által a dokumentumhoz tartozó jogosultságok listáját (ha vannak ilyenek). A felhasználó azonosításához a Microsoft Entra ProxyAddresses attribútumot használja a rendszer annak a felhasználónak a fiókjához és csoportjaihoz, amelyeknek a felhasználó tagja. Teljesítménybeli okokból a csoporttagság gyorsítótárazva van. Ha a felhasználói fiók nem tartalmaz értékeket a Microsoft Entra ProxyAddresses attribútumhoz, a Rendszer ehelyett a Microsoft Entra UserPrincipalName értékét használja.

Mi történik a 2. lépésben: A szolgáltatás ezután kinyeri az AES-tartalomkulcsot a visszafejtött szabályzatból. Ezt a kulcsot ezután a rendszer a kéréssel beszerzett nyilvános RSA-kulccsal titkosítja.

Az újratitkosított tartalomkulcs ezután beágyazódik egy titkosított használati licencbe a felhasználói jogosultságok listájával, amelyet a rendszer visszaad az RMS-ügyfélnek.

Mi történik a 3. lépésben: Végül az RMS-ügyfél felveszi a titkosított használati licencet, és visszafejti azt saját felhasználói titkos kulcsával. Ez lehetővé teszi, hogy az RMS-ügyfél a szükséges módon visszafejtse a dokumentum törzsét, és megjelenítse a képernyőn.

Az ügyfél emellett visszafejti a jogosultságlistát, és átadja őket az alkalmazásnak, amely kikényszeríti ezeket a jogokat az alkalmazás felhasználói felületén.

Megjegyzés:

Ha a szervezeten kívüli felhasználók az Ön által védett tartalmakat használnak fel, a használati folyamat ugyanaz. Ebben a forgatókönyvben az a változás, hogy a felhasználó hitelesítése hogyan történik. További információ: Ha megosztok egy védett dokumentumot a cégen kívüli valakivel, hogyan történik a felhasználó hitelesítése?

Változatok

Az előző útmutatók a standard forgatókönyveket ismertetik, de vannak változatok:

• E-mail-védelem: Ha az Exchange Online és az Office 365 üzenettitkosítása új képességekkel védi az e-maileket, a használatalapú hitelesítés a közösségi identitásszolgáltatóval való összevonást vagy egyszeri pin-kód használatát is használhatja. Ezután a folyamatfolyamatok nagyon hasonlóak, azzal a kivételrel, hogy a tartalomfogyasztás szolgáltatásoldalon történik egy webböngésző-munkamenetben a kimenő e-mailek ideiglenesen gyorsítótárazott példányán keresztül.

• Mobileszközök: Ha a mobileszközök védik vagy felhasználják a fájlokat a Azure Tartalomvédelmi szolgáltatások szolgáltatással, a folyamat sokkal egyszerűbb. A mobileszközök nem először haladnak végig a felhasználó inicializálási folyamatán, mert ehelyett minden tranzakció (a tartalom védelme vagy felhasználása érdekében) független. A Windows rendszerű számítógépekhez hasonlóan a mobileszközök is csatlakoznak a Azure Tartalomvédelmi szolgáltatások szolgáltatáshoz, és hitelesítik magukat. A tartalmak védelme érdekében a mobileszközök szabályzatot küldenek, és a Azure Tartalomvédelmi szolgáltatások szolgáltatás elküldi nekik a közzétételi licencet és a szimmetrikus kulcsot a dokumentum védelméhez. A tartalom felhasználásához, amikor a mobileszközök csatlakoznak a Azure Tartalomvédelmi szolgáltatások szolgáltatáshoz és hitelesítik őket, elküldik a dokumentumszabályzatot a Azure Tartalomvédelmi szolgáltatások szolgáltatásnak, és használati licencet kérnek a dokumentum használatához. Válaszul a Azure Tartalomvédelmi szolgáltatások szolgáltatás elküldi a szükséges kulcsokat és korlátozásokat a mobileszközöknek. Mindkét folyamat A TLS használatával védi a kulcscserét és az egyéb kommunikációt.

• RMS-összekötő: Ha a Azure Tartalomvédelmi szolgáltatások szolgáltatást használja az RMS-összekötővel, a folyamatfolyamatok változatlanok maradnak. Az egyetlen különbség az, hogy az összekötő továbbítóként működik a helyszíni szolgáltatások (például az Exchange Server és a SharePoint Server) és a Azure Tartalomvédelmi szolgáltatások szolgáltatás között. Maga az összekötő nem hajt végre semmilyen műveletet, például a felhasználói környezet inicializálását, titkosítást vagy visszafejtést. Egyszerűen továbbítja a kommunikációt, amely általában egy AD RMS-kiszolgálóra kerül, és kezeli a fordítást az egyes oldalon használt protokollok között. Ez a forgatókönyv lehetővé teszi, hogy a Azure Tartalomvédelmi szolgáltatások szolgáltatást helyszíni szolgáltatásokkal használja.

• Általános védelem (.pfile): Ha a Azure Tartalomvédelmi szolgáltatások szolgáltatás általánosan védi a fájlokat, a folyamat alapvetően ugyanaz a tartalomvédelem esetében, kivéve, hogy az RMS-ügyfél létrehoz egy szabályzatot, amely minden jogosultságot biztosít. A fájl felhasználásakor a rendszer visszafejti, mielőtt a célalkalmazásnak továbbítanák. Ez a forgatókönyv lehetővé teszi az összes fájl védelmét, még akkor is, ha natív módon nem támogatják az RMS-t.

• Microsoft-fiókok: Az Azure Information Protection engedélyezheti az e-mail-címeket felhasználás céljából, ha azok hitelesítése Microsoft-fiókkal történik. Azonban nem minden alkalmazás nyithat meg védett tartalmat, ha a hitelesítéshez Microsoft-fiókot használnak. További információ.

További lépések

A Azure Tartalomvédelmi szolgáltatások szolgáltatással kapcsolatos további információkért használja a Megértés és felfedezés szakaszban található egyéb cikkeket, például azt, hogy az alkalmazások hogyan támogatják a Azure Tartalomvédelmi szolgáltatások szolgáltatást, hogy megismerje, hogyan integrálhatók a meglévő alkalmazások a következőkkel: Azure Tartalomvédelmi szolgáltatások információvédelmi megoldás biztosításához.

Tekintse át az Azure Information Protection terminológiáját, hogy megismerje azokat a kifejezéseket, amelyekkel a Azure Tartalomvédelmi szolgáltatások szolgáltatás konfigurálásakor és használatakor találkozhat, és az üzembe helyezés megkezdése előtt ellenőrizze az Azure Information Protection követelményeit is. Ha azonnal bele szeretne merülni, és kipróbálná magát, használja a rövid útmutatót és az oktatóanyagokat:

• Rövid útmutató: Az egyesített címkézési ügyfél üzembe helyezése
• Oktatóanyag: Az Azure Information Protection (AIP) egységes címkézési szkennerének telepítése
• Oktatóanyag: Bizalmas tartalom megkeresése az Azure Information Protection (AIP) szkennerrel
• Oktatóanyag: A túlmegosztás megakadályozása az Outlookban az Azure Information Protection (AIP) használatával

Ha készen áll arra, hogy megkezdje az adatvédelem üzembe helyezését a szervezet számára, használja az AIP üzembe helyezési ütemtervét az üzembe helyezési lépések besorolásához, címkézéséhez és védelméhez , valamint útmutatókra mutató hivatkozásokat.

Tipp.

További információkért és segítségért használja az Azure Information Protection információinak és támogatásának erőforrásait és hivatkozásait.