Zugriffssteuerung verwalten

Auf dieser Seite finden Sie einen Überblick darüber, wie Sie die Zugriffssteuerung für Projekte und Dokumente verwalten.

Übersicht über die Datenzugriffssteuerung

Die Datenzugriffssteuerung ist eine wichtige Funktion von Document AI Warehouse. Damit wird gesteuert, wer Zugriff auf welche Ressource in Document AI Warehouse hat und welche Zugriffsebene die betreffenden Nutzer haben.

Document AI Warehouse APIs basieren auf Google Cloud. HTTPS wird verwendet, um eine sichere Datenübertragung über das Internet zu gewährleisten. Authentifizierung und Autorisierung werden für die Document AI Warehouse-APIs erzwungen, um den Dienst und Nutzerdaten auf Grundlage von Google-Identitäten zu schützen.

Document AI Warehouse APIs verwenden OAuth2 zur Authentifizierung mit einem Nutzerkonto. Für alle API-Methoden ist der OAuth-Bereich https://www.googleapis.com/auth/cloud-platform erforderlich.

Document AI Warehouse erzwingt die Zugriffssteuerung für Kundendaten basierend auf Cloud IAM. In Document AI Warehouse sind eine Reihe von Rollen und zugehörigen Berechtigungen definiert, mit denen Sie den Zugriff verschiedener Nutzer auf die in unserem Dienst gespeicherten Daten einschränken können. Weitere Informationen finden Sie im Abschnitt IAM-Rollen und -Berechtigungen.

Mit einem Dienstkonto die grundlegende Zugriffssteuerung erzwingen

Sie benötigen ein Dienstkonto mit den erforderlichen Berechtigungen für den Zugriff auf die Document AI Warehouse API. Wenn Sie in der Kurzanleitung den Schritt „Bereitstellung über die Google Cloud Console“ ausführen, wird automatisch ein Dienstkonto mit der Rolle „Document AI Warehouse-Administrator“ bereitgestellt.

Zugriffssteuerungsmodus

Document AI Warehouse bietet drei Zugriffssteuerungsmodi:

Universalzugriff: Keine Zugriffssteuerung auf Dokumentebene
Zugriffssteuerung auf Dokumentebene mit Ihrem eigenen Identitätsdienst
Zugriffssteuerung auf Dokumentebene mit Cloud Identity

Nutzer müssen während der Bereitstellung einen der Zugriffsmodi auswählen. In den folgenden Abschnitten wird der Unterschied zwischen den drei Zugriffssteuerungsmodi erläutert und gezeigt, wie Sie die einzelnen Modi aktivieren.

Universalzugriff

Mit der universellen Zugriffssteuerung können Sie Berechtigungen allein mit Identity and Access Management (IAM) verwalten. IAM wendet dieselben Berechtigungen auf alle Dokumente im Projekt mit der authentifizierten Identität an.

Wenn Sie die Bereitstellungsprozedur im Schnellstart abgeschlossen haben, können Sie und alle Ihre Nutzer in diesem Modus mit dem Dienstkonto und den damit verknüpften Berechtigungen auf alle Dokumente im ausgewählten Google Cloud-Projekt im Document AI Warehouse-Dienst zugreifen.

Im weiteren Verlauf dieses Dokuments wird die Zugriffssteuerung auf Dokumentebene behandelt. Wenn Sie den Universalzugriff verwenden, können Sie den Rest des Dokuments überspringen.

Zugriffssteuerung auf Dokumentebene

Document AI Warehouse-Nutzer haben folgende Möglichkeiten:

Eigenen Identitätsdienst verwenden
- Sowohl der Endnutzer als auch die Mitgliedschaftsgruppen des Endnutzers sind in den Anfragemetadaten erforderlich. Wenn Ihr Unternehmen eine eigene Methode zur Authentifizierung des Nutzers und zur Ermittlung der Gruppen hat, zu denen der Nutzer gehört, verwenden Sie diese Option.
Cloud Identity verwenden
- In den Anfragemetadaten ist nur der Endnutzer erforderlich, da Document AI Warehouse die Mitgliedschaftsgruppen für Kunden aus Cloud Identity abruft. Der Unterschied zur Verwendung eines benutzerdefinierten Identitätsdienstes besteht darin, dass Sie die Gruppenmitgliedschaften des Nutzers mit Cloud Identity anstelle eines internen Systems verwalten.

Bei der Verwendung des Zugriffsmodus auf Dokumentebene gibt es einige Einschränkungen:

Es werden nur Mitglieder und Rollen in der ACL unterstützt. IAM-Bedingungen werden ignoriert.
Benutzerdefinierte Rollen werden in der ACL nicht unterstützt.
Document AI Warehouse überprüft die Anmeldedaten von Endnutzern nicht. Document AI Warehouse überprüft nur die Anmeldedaten des Dienstkontos, um sicherzustellen, dass die Aufrufe von den Kunden stammen. Die Anmeldedaten von Endnutzern müssen vom Kunden überprüft werden.
Kunden müssen den Endnutzer (und alle Gruppen, denen der Endnutzer angehört, wenn die Cloud Identity-Option nicht verwendet wird) in den Metadaten der Anfrage angeben, um die Zugriffssteuerung zu erzwingen.
Die Anzahl der Mitgliedschaftsgruppen für den Endnutzer sollte weniger als 100 betragen.

Zugriffssteuerung auf Dokumentebene mit dem Identitätsdienst des Kunden

Sie können diesen Modus auswählen, wenn Sie Folgendes tun möchten:

Endnutzern (Gruppen) unterschiedliche Berechtigungen für den Zugriff auf die einzelnen Dokumente erteilen.
Eigenen Identitätsdienst verwenden

In diesem Modus können Sie IAM und Zugriffssteuerungslisten (Access Control Lists, ACLs) gemeinsam zur Verwaltung von Berechtigungen verwenden. Für jedes Dokument in Document AI Warehouse kann eine bestimmte ACL auf Dokumentebene konfiguriert werden. Die Authentifizierung und Autorisierung erfolgt so:

Die Anmeldedaten des Dienstkontos sind authentifiziert und autorisiert, um auf den Dienst zuzugreifen.
Nehmen Sie in die Metadaten der Anfrage den Endnutzer und die Gruppen auf, denen er angehört. Entweder der Endnutzer oder mindestens eine der Gruppen, zu denen der Endnutzer gehört, muss die Berechtigung zum Zugriff auf das Dokument haben.

Document AI Warehouse gewährt nur dann Zugriff auf das angeforderte Dokument, wenn beide Bedingungen in der obigen Liste erfüllt sind.

Die UserInfo (einschließlich der Endnutzer-ID und der IDs der Mitgliedschaftsgruppen des Nutzers) des RequestMetadata, das im API-Aufruf angegeben ist, wird verwendet, um zu prüfen, ob der Endnutzer die entsprechende Aktion für die angeforderte Dokumentressource ausführen darf. Beispielsweise wird die UserInfo, die in der GetDocument API bereitgestellt wird, verwendet, um zu prüfen, ob der Endnutzer das Dokument ansehen darf. Wenn entweder der Endnutzer oder eine der Mitgliedschaftsgruppen das Dokument aufrufen darf, darf der Endnutzer das Dokument aufrufen.

Beispiel für RequestMetadata im JSON-Format:

request_metadata: {
    user_info: {
        id: user:fake_user_id
        group_ids: [
            group:fake_group_id_1,
            group:fake_group_id_2,
            group:fake_group_id_3,
        ]
    }
}

Zusätzlich zur Kurzanleitung sind für diesen Zugriffssteuerungsmodus einige zusätzliche Schritte erforderlich, bevor Sie APIs an Document AI Warehouse senden können:

Rufen Sie Gruppenmitgliedschaften für einen bestimmten Endnutzer aus Ihrem Verzeichnisdienst ab, z. B. Azure Active Directory oder Okta.
Folgen Sie der Anleitung im Abschnitt Zugriffssteuerung konfigurieren, um eine Standardprojektrichtlinie festzulegen. Sie können auch nach der Erstellung eine ACL auf Dokumentebene für bestimmte Dokumente festlegen.

Nachdem Sie die vorherigen Schritte ausgeführt haben, können Sie das Dienstkonto verwenden, um API-Aufrufe an Document AI Warehouse zu senden. Die Informationen zu Endnutzern und Gruppenmitgliedschaften werden dabei im Abschnitt RequestMetadata des Anfragetexts angegeben.

In diesem Modus sollten Sie einen Proxy bereitstellen, um die Endnutzer zu authentifizieren und zu autorisieren. Der Proxy verwendet das Dienstkonto mit der Administratorrolle, um auf den Dienst zuzugreifen. Der Dienstkontoschlüssel sollte so geschützt werden, dass er nur vom Proxy verwendet wird.

Als sofort einsatzbereite Lösung ist die Document AI Warehouse-Konsole ein Proxy, in dem der Dienstkontoschlüssel gespeichert werden kann, die Endnutzer über die Google-Identitäten authentifiziert werden und die Anfragen an Document AI Warehouse weitergeleitet werden.

Zugriffssteuerung auf Dokumentebene mit Cloud Identity

Alternativ zur Verwendung Ihres eigenen Identitätsdienstes können Sie auch Cloud Identity verwenden, um den Prozess zu vereinfachen.

Um Nutzer und Gruppen zentral zu verwalten, können Google Cloud Kunden Cloud Identity von Grund auf einrichten oder Identitäten zwischen Google und anderen Identitätsanbietern wie Active Directory und Azure Active Directory föderieren.

Der Abschnitt UserInfo von RequestMetadata, der im API-Aufruf angegeben ist, wird verwendet, um zu prüfen, ob der Endnutzer die entsprechende Aktion für die angeforderte Dokumentressource ausführen darf. Bei Verwendung von Cloud Identity ist nur die Endnutzer-ID im RequestMetadata erforderlich. Document AI Warehouse ruft die Informationen zur Mitgliedschaftsgruppe aus dem Cloud Identity-Dienst ab. Wenn entweder der Endnutzer oder eine der Mitgliedschaftsgruppen auf das Dokument zugreifen darf, darf der Endnutzer auf das Dokument zugreifen.

Beispiel für RequestMetadata im JSON-Format:

request_metadata: {
    user_info: {
        id: user:fake_user_id
    }
}

Zusätzlich zur Kurzanleitung sind für diesen Zugriffssteuerungsmodus einige zusätzliche Schritte erforderlich, bevor Sie Anfragen an Document AI Warehouse senden können:

Integration mit Cloud Identity für Endnutzer und Gruppen.
Folgen Sie der Anleitung im Abschnitt Zugriffssteuerung konfigurieren, um eine Standardprojektrichtlinie festzulegen. Sie können auch nach der Erstellung eine ACL auf Dokumentebene für bestimmte Dokumente festlegen.

Nachdem Sie die vorherigen Schritte ausgeführt haben, können Sie das Dienstkonto verwenden, um API-Aufrufe an Document AI Warehouse mit Endnutzerinformationen im Abschnitt RequestMetadata des Anfrage-Bodys zu senden.

Zugriffssteuerung konfigurieren

Hinweise

Bevor Sie beginnen, müssen Sie die Seite Schnellstart durcharbeiten.

SetAcl und FetchAcl

Wenn ein neues Projekt erstellt wird, wird keine Projekt-ACL festgelegt. Der Projektinhaber kann die Document AI Warehouse-API SetAcl aufrufen, um eine Standard-Projektrichtlinie für das Projekt festzulegen. Dazu wird das Feld projectOwner mit dem Dienstkonto auf „true“ gesetzt und vordefinierte Rollen für das Projekt verwendet. Mitglieder der Projektrichtlinie haben je nach zugewiesenen Rollen Zugriff auf alle Dokumente im Projekt. Sie können Administratornutzern oder -gruppen den Zugriff in der Standardprojektrichtlinie gewähren.

In der folgenden Tabelle ist die erforderliche Rolle für jede Dokumentaktion zusammengefasst. Weitere Informationen zu den Berechtigungen, die jeder Rolle gewährt werden, finden Sie unter IAM-Rollen und -Berechtigungen.

Informationen zum Ausführen von Aufrufen an die Document Schema API mit dem Dienstkonto finden Sie unter projects.locations.documentSchemas.

Document API-Methode	Erforderliche Rollen
`CreateDocument`	`roles/contentwarehouse.documentCreator`
`UpdateDocument`	`roles/contentwarehouse.documentEditor`
`DeleteDocument` `SetACL`	`roles/contentwarehouse.documentAdmin`
`GetDocument` `FetchACL` `SearchDocuments`	`roles/contentwarehouse.documentViewer`

CreateDocument

Gewähren Sie dem Endnutzer oder der Gruppe Erstellerzugriff, falls dieser noch nicht gewährt wurde:

[Optional] Mitgliedschaftsgruppen für den Endnutzeradministrator aus dem Identitätsdienst des Kunden abrufen. Dieser Schritt kann für Kunden, die Cloud Identity verwenden, übersprungen werden.
Weisen Sie dem Endnutzer A (oder der Gruppe, der Nutzer A angehört) die Rolle roles/contentwarehouse.documentCreator auf Projektebene zu, indem Sie den Aufruf an SetAcl mit dem Dienstkonto mit dem Endnutzeradministrator [und den Mitgliedschaftsgruppen] in den Anfragemetadaten ausführen. Der Endnutzer-Administrator hat documentAdmin-Zugriff auf Projektebene.

Dokument erstellen:

Optional: Rufen Sie die Mitgliedschaftsgruppen für Endnutzer A aus Ihrem Identitätsdienst ab. Wenn Sie Cloud Identity verwenden, können Sie diesen Schritt überspringen.
Rufen Sie CreateDocument mit dem Endnutzer A [und den Mitgliedschaftsgruppen] in den Anfragemetadaten auf, um ein Dokument mit dem Dienstkonto zu erstellen. Nachdem das Dokument erstellt wurde, kann Endnutzer A es standardmäßig ansehen und bearbeiten. Kunden können auch eine Standardrichtlinie angeben, um Nutzern oder Gruppen beim Erstellen Zugriff zu gewähren. Beispiel: GruppeX erhält documentViewer-Zugriff, GruppeY documentEditor-Zugriff und GruppeZ documentAdmin-Zugriff.

GetDocument und FetchAcl

Nachdem das Dokument erstellt wurde, können Endnutzer A oder die Mitglieder von GruppeX, GruppeY oder GruppeZ GetDocument aufrufen, um das Dokument aufzurufen, oder FetchAcl, um die ACL des Dokuments aufzurufen. Gehen Sie wie folgt vor:

Optional: Rufen Sie die Mitgliedschaftsgruppen für Endnutzer A aus Ihrem Identitätsdienst ab. Wenn Sie Cloud Identity verwenden, können Sie diesen Schritt überspringen.
Rufen Sie GetDocument oder FetchAcl mit dem Dienstkonto und Endnutzer A (und Mitgliedschaftsgruppen) in den Anfragemetadaten auf.

Der Anruf von Endnutzer B wird abgelehnt, wenn B kein Mitglied von groupX, groupY oder groupZ ist.

UpdateDocument, DeleteDocument und SetAcl

Nachdem das Dokument erstellt wurde, dürfen nur Endnutzer A oder Mitglieder von GruppeY oder GruppeZ UpdateDocument aufrufen, um das Dokument zu aktualisieren. Nur Endnutzer A oder Mitglieder von GruppeZ dürfen DeleteDocument aufrufen, um das Dokument zu löschen, oder SetAcl, um das Dokument für andere Endnutzer oder Gruppen freizugeben. Gehen Sie wie folgt vor:

Optional: Rufen Sie die Mitgliedschaftsgruppen für Endnutzer A aus Ihrem Identitätsdienst ab. Wenn Sie Cloud Identity verwenden, können Sie diesen Schritt überspringen.
Rufen Sie UpdateDocument, DeleteDocument oder SetAcl mit dem Dienstkonto mit Endnutzer A [und Mitgliedschaftsgruppen] in den Anforderungsmetadaten auf.

Der Anruf von Mitgliedern der GruppeX wird abgelehnt, da sie nur documentViewer-Zugriff auf das Dokument haben.

SearchDocuments

Die zurückgegebenen Dokumente hängen von den Rollen ab, die dem Endnutzer zugewiesen sind. Bei einer leeren Suchanfrage werden beispielsweise alle Dokumente unter dem Projekt zurückgegeben, wenn der Endnutzer documentViewer-Zugriff auf Projektebene hat. Andernfalls werden nur die Dokumente mit der Berechtigung contentwarehouse.documents.get für den angegebenen Endnutzer zurückgegeben.

Um die SearchDocument-API aufzurufen, müssen Kunden die folgenden Schritte ausführen.

Optional: Rufen Sie die Mitgliedschaftsgruppen für Endnutzer A aus Ihrem Identitätsdienst ab. Wenn Sie Cloud Identity verwenden, können Sie diesen Schritt überspringen.
Rufen Sie SearchDocument mit dem Dienstkonto und Endnutzer A (und Mitgliedschaftsgruppen) in den Anfragemetadaten auf.

Document Link APIs

Document Link API-Methode	Erforderliche Rollen
`CreateDocumentLink`	Quelle: `roles/contentwarehouse.documentEditor` Ziel: `roles/contentwarehouse.documentViewer`
`ListLinkedTargets` `ListLinkedSources`	`roles/contentwarehouse.documentViewer`
`DeleteDocumentLink`	Quelle: `roles/contentwarehouse.documentEditor`

CreateDocumentLink

Endnutzer können die Dokumente doc1 und doc2 verknüpfen, wenn sie die Berechtigung contentwarehouse.documents.update für doc1 und die Berechtigung contentwarehouse.documents.get für doc2 haben.

ListLinkedTargets und ListLinkedSources

Endnutzer können nur die Zieldokumente oder Quelldokumente mit der Berechtigung contentwarehouse.documents.get auflisten.

DeleteDocumentLink

Endnutzer können die Links löschen, wenn sie die Berechtigung contentwarehouse.documents.update für die Quelldokumente haben.