Étapes de configuration et rôles Référence des autorisations Valeurs que vous collectez lors de la configuration Étape 1 : enregistrer l'application dans Microsoft Entra ID Étape 2 : ajouter des autorisations d'API et accorder le consentement de l'administrateur Étape 3 : Création d'un secret client Étape 4 (ACL uniquement) : générer le certificat d'authentification Étape 5 (ACL uniquement) : Téléchargez le certificat public sur Entra Étape 6 (ACL uniquement) : chargez le certificat sur Amazon S3 Étape 7 : Création du secret du Gestionnaire de Secrets Étape 8 (ACL uniquement) : accorder au rôle de service l'accès au certificat Étapes suivantes

Configurer l'authentification Microsoft Entra App ID pour OneDrive

L'authentification Microsoft Entra App ID (ENTRA_APP_ID) est la méthode d'authentification recommandée pour une source de OneDrive données. Le connecteur analyse le contenu à l'aide du flux d'informations d'identification du client OAuth 2.0 (application uniquement), en utilisant l'ID client et le secret de votre application. Aucune connexion utilisateur n'est requise. Il s'agit de la seule méthode d'authentification qui prend en charge le contrôle d'accès au niveau du document (ACL). Pour une comparaison avec la OAUTH2 méthode alternative, voirMéthodes d’authentification.

Note

Un certificat n'est requis que lorsque vous activez le contrôle d'accès au niveau du document. Pour l'analyse du contenu uniquement, l'ID client et le code secret sont les seules informations d'identification dont le connecteur a besoin. Cela diffère d'une source de SharePoint données, où l' App-Only authentification Microsoft Entra ID nécessite toujours un certificat.

Accès administratif requis

Cette configuration nécessite un administrateur Microsoft Entra ID (administrateur global ou administrateur de rôles privilégiés) pour enregistrer l'application, configurer les autorisations et accorder le consentement de l'administrateur. Le tableau des étapes de configuration et des rôles ci-dessous indique l'accès requis pour chaque étape.

Étapes de configuration et rôles

Cette procédure implique à la fois un administrateur Microsoft Entra ID et un AWS administrateur. Selon la répartition des responsabilités au sein de votre organisation, une ou plusieurs personnes peuvent effectuer ces étapes. Les étapes du certificat (étapes 4 à 6 et 8) s'appliquent uniquement lorsque vous activez le contrôle d'accès au niveau du document. Utilisez le tableau suivant pour identifier l'accès requis par chaque étape.

Étapes de configuration et accès requis pour chacune
Step (Étape)	Ce que tu fais	Accès nécessaire
1. Enregistrez l'application	Créez l'enregistrement de l'application Entra et enregistrez ses identifiants de client et de locataire.	Administrateur Microsoft Entra ID (administrateur global ou administrateur de rôles privilégiés)
2. Ajouter des autorisations et accorder le consentement	Attribuez les autorisations d'application pour votre configuration et accordez le consentement de l'administrateur.	Administrateur Microsoft Entra ID
3. Création d'un secret client	Créez un secret client pour l'application et enregistrez sa valeur.	Administrateur Microsoft Entra ID
4. Générer le certificat (ACL uniquement)	Créez un certificat auto-signé et un bundle PKCS #12 (`.p12`) avec OpenSSL.	Toute personne disposant d'un terminal local (OpenSSL requis)
5. Téléchargez le certificat public sur Entra (ACL uniquement)	Ajoutez le certificat public aux clés d'enregistrement de l'application.	Administrateur Microsoft Entra ID
6. Téléchargez le certificat sur Amazon S3 (ACL uniquement)	Stockez le `.p12` bundle dans un compartiment Amazon S3.	AWS administrateur (Amazon S3)
7. Créez le secret.	Conservez les informations d'identification dans un AWS Secrets Manager secret.	AWS administrateur (Secrets Manager)
8. Accorder au rôle de service l'accès au certificat (ACL uniquement)	Ajoutez des autorisations de lecture Amazon S3 à votre rôle de service de base de connaissances.	AWS administrateur (IAM)

Référence des autorisations

Attribuez les autorisations d'application correspondant à votre configuration. Toutes les autorisations sont des autorisations d'application (non déléguées), et chacune nécessite le consentement de l'administrateur. Pour l'analyse du contenu uniquement, le connecteur s'authentifie uniquement auprès de Microsoft Graph. Lorsque le contrôle d'accès au niveau du document est activé, le connecteur s'authentifie également auprès de l'SharePointAPI REST pour vérifier l'accès au moment de la requête, car OneDrive for Business est soutenu par. SharePoint

Important

Lorsque vous ajoutez ces autorisations dans le portail Entra, choisissez l'onglet Autorisations de l'application, et non Autorisations déléguées. Application-only l'authentification utilise les autorisations des applications.

Sélectionnez l'onglet correspondant à votre configuration pour voir les autorisations exactes à attribuer.

Content only (no ACLs)

Contenu uniquement
API	Autorisations	Objectif
Microsoft Graph	`Files.Read.All`	Lisez les fichiers qui se trouvent sur le disque dur des utilisateurs.
Microsoft Graph	`Sites.Read.All`	Lisez les OneDrive sites qui sauvegardent les disques durs des utilisateurs.
Microsoft Graph	`User.Read.All`	Énumérez les utilisateurs dont vous parcourez les disques.

With ACLs

Avec ACL
API	Autorisations	Objectif
Microsoft Graph	`Files.Read.All`	Lisez les fichiers qui se trouvent sur le disque dur des utilisateurs.
Microsoft Graph	`Sites.Read.All`	Lisez les OneDrive sites qui sauvegardent les disques durs des utilisateurs.
Microsoft Graph	`User.Read.All`	Énumérez les utilisateurs et résolvez-les pour les ACL au niveau du document.
Microsoft Graph	`GroupMember.Read.All`	Résolvez l'appartenance à un groupe pour les ACL au niveau du document.
SharePoint	`Sites.FullControl.All`	Vérifiez l'accès de chaque utilisateur à un document au moment de la requête. `Sites.Read.All`n'est pas suffisant pour cette vérification.

Note

L' SharePoint Sites.FullControl.Allautorisation accorde à l'application du connecteur un accès étendu à tous les sites de votre locataire. Accordez-le uniquement à cette application et protégez les informations d'identification de l'application en conséquence.

Valeurs que vous collectez lors de la configuration

Vous créez ou collectez les valeurs suivantes au fur et à mesure que vous suivez les étapes. Vous les utilisez lorsque vous créez la source de données. Pour en savoir plus, consultez Connecter une source OneDrive de données.

Référence de valeurs
Value	Créé en	Utilisé pour
ID de l’application (client)	Étape 1	Le secret (`clientId`).
ID du répertoire (locataire)	Étape 1	La source de données`tenantId`.
Valeur secrète du client	Étape 3	Le secret (`clientSecret`).
Certificat — paquet PKCS #12 (`.p12`) et son mot de passe (ACL uniquement)	Étape 4	Le bundle (certificat et clé privée) est chargé sur Amazon S3 (étape 6) ; le mot de passe est stocké dans le secret (`certificatePassword`).
Certificat — certificat public (`.cer`) (ACL uniquement)	Étape 4	La moitié publique du même certificat, téléchargée lors de l'enregistrement de l'application Entra (étape 5).
Nom et clé du compartiment Amazon S3 (ACL uniquement)	Étape 6	La source de données`certificateS3Path`.
ARN du secret	Étape 7	La source de données`secretArn`.

Étape 1 : enregistrer l'application dans Microsoft Entra ID

Connectez-vous au centre d’administration Microsoft Entra.
Dans le menu de navigation de gauche, développez Entra ID et choisissez App registration.
Choisissez Nouvel enregistrement.
Dans Nom, entrez un nom descriptif, tel quebedrock-onedrive-connector.
Pour les types de comptes pris en charge, sélectionnez Comptes dans ce répertoire organisationnel uniquement (locataire unique).
Laissez l'URI de redirection vide. Un URI de redirection n'est pas nécessaire car l'application utilise le flux d'informations d'identification du client, et non un flux de connexion interactif.
Choisissez S’inscrire.
Sur la page Présentation de l'application, enregistrez l'ID de l'application (client) et l'ID du répertoire (locataire). Tu auras besoin des deux plus tard.

Étape 2 : ajouter des autorisations d'API et accorder le consentement de l'administrateur

Ajoutez les autorisations pour votre configuration à partir deRéférence des autorisations.

Lors de l'enregistrement de votre application, choisissez Autorisations API, puis Ajouter une autorisation.
Choisissez Microsoft Graph, puis Autorisations de l'application. Recherchez et sélectionnez chaque autorisation Microsoft Graph pour votre configuration, puis choisissez Ajouter des autorisations.
Si vous activez le contrôle d'accès au niveau du document, choisissez à nouveau Ajouter une autorisation. Choisissez SharePoint(sous Microsoft APIs), puis Autorisations de l'application. SélectionnezSites.FullControl.All, puis choisissez Ajouter des autorisations.
Sur la page des autorisations d'API, choisissez Accorder le consentement de l'administrateur pour [votre organisation] et confirmez. Sans le consentement de l'administrateur, l'application ne peut pas accéder aux OneDrive données.

Étape 3 : Création d'un secret client

OneDrive le crawling utilise l'ID client et le secret de l'application, de sorte qu'un secret client est requis à la fois pour le contenu uniquement et ACL-enabled pour les sources de données. Lorsque le contrôle d'accès au niveau du document est activé, le connecteur utilise le secret du client pour obtenir un jeton Microsoft Graph qui résout l' OneDrive hôte de votre locataire, et le certificat (issu de l'étape 4) pour obtenir le SharePoint jeton utilisé pour le contrôle d'accès.

Lors de l'enregistrement de votre application, choisissez Certificats et secrets, puis Secrets client, puis Nouveau secret client.
Entrez une description, choisissez une date d'expiration, puis cliquez sur Ajouter.
Enregistrez immédiatement la valeur secrète : elle n'est affichée qu'une seule fois. Enregistrez la valeur, pas l'identifiant secret.

Étape 4 (ACL uniquement) : générer le certificat d'authentification

Note

Cette étape et les étapes 5, 6 et 8 ne s'appliquent que si vous activez le contrôle d'accès au niveau du document. Pour l'exploration du contenu uniquement, passez à. Étape 7 : Création du secret du Gestionnaire de Secrets

Générez un certificat auto-signé et empaquetez-le sous forme de bundle PKCS #12 (.p12). Le bundle contient à la fois le certificat et sa clé privée, protégés par un mot de passe. Vous chargez le certificat public vers Entra (étape 5) et le .p12 bundle vers Amazon S3 (étape 6). Sélectionnez l'onglet correspondant à votre système d'exploitation pour voir les commandes.

Note

Amazon Bedrock lit la clé privée du .p12 bundle pour signer les assertions d'authentification. Le bundle doit donc être protégé par mot de passe. Choisissez un mot de passe fort et aléatoire. Vous le stockez dans le secret comme certificatePassword à l'étape 7.

Linux or macOS (OpenSSL)

Génération d'une clé privée et d'un certificat auto-signé


openssl req -x509 -newkey rsa:2048 -keyout private_key.pem -out certificate.cer \
    -days 365 -nodes \
    -subj "/CN=bedrock-onedrive-connector"

Package du certificat et de la clé sous forme de bundle PKCS #12 (.p12)

Entrez un mot de passe d'exportation robuste lorsque vous y êtes invité. Enregistrez-le pour l'étape 7.


openssl pkcs12 -export -out certificate.p12 \
    -inkey private_key.pem -in certificate.cer

Vous disposez désormais de trois fichiers : la clé privée (private_key.pem), le certificat public (certificate.cer) et le bundle (certificate.p12). Vous chargez le certificat public sur Entra à l'étape 5 et le .p12 bundle sur Amazon S3 à l'étape 6.

Windows (PowerShell)

Génération d'un certificat auto-signé

Les PowerShell commandes suivantes génèrent un certificat autosigné RSA de 2048 bits avec une période de validité d'un an et le stockent dans le magasin de certificats de l'utilisateur actuel. your-passwordRemplacez-le par un mot de passe fort et aléatoire. Vous le stockez dans le secret comme certificatePassword à l'étape 7.


$cert = New-SelfSignedCertificate `
    -Subject "CN=bedrock-onedrive-connector" `
    -CertStoreLocation "Cert:\CurrentUser\My" `
    -KeyAlgorithm RSA `
    -KeyLength 2048 `
    -KeyExportPolicy Exportable `
    -NotAfter (Get-Date).AddYears(1)

Exporter le certificat public


Export-Certificate -Cert $cert -FilePath certificate.cer -Type CERT

Exportez le bundle PKCS #12 (.p12)


$password = ConvertTo-SecureString -String "your-password" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath certificate.p12 -Password $password

Vous avez maintenant deux fichiers : le certificat public (certificate.cer) et le bundle (certificate.p12). Vous chargez le certificat public sur Entra à l'étape 5 et le .p12 bundle sur Amazon S3 à l'étape 6.

Important

Stockez le .p12 bundle dans Amazon S3 (et non dans le .cer fichier .pem or). Le bundle contient la clé privée qu'Amazon Bedrock utilise SharePoint pour s'authentifier à des fins de vérification d'accès. Conservez-la donc en toute sécurité. Document-level le contrôle d'accès nécessite le .p12 format.

Note

Le certificat est valide pendant un an par défaut. Un certificat expiré entraîne l'échec de toutes les synchronisations. Faites donc pivoter le certificat avant son expiration. Pour modifier la période de validité, ajustez l'-daysoption (OpenSSL) ou -NotAfter l'argument (). PowerShell Pour les étapes de rotation, voirFaites pivoter le certificat.

Étape 5 (ACL uniquement) : Téléchargez le certificat public sur Entra

Lors de l'enregistrement de votre application, choisissez Certificats et secrets, puis l'onglet Certificats.
Choisissez Télécharger le certificat et sélectionnez le certificate.cer fichier que vous avez généré à l'étape 4 (le certificat public uniquement ; ne téléchargez jamais le .p12 bundle ou la clé privée dans Entra).
Choisissez Ajouter.

Étape 6 (ACL uniquement) : chargez le certificat sur Amazon S3

Téléchargez le .p12 bundle de l'étape 4 vers un compartiment Amazon S3 situé dans la même AWS région que votre base de connaissances. Enregistrez le nom et la clé du compartiment : vous les utilisez comme source de donnéescertificateS3Path.


aws s3api put-object \
  --bucket your-certificate-bucket \
  --key certs/certificate.p12 \
  --body certificate.p12 \
  --server-side-encryption AES256

Note

Nous vous recommandons d'activer le chiffrement côté serveur sur l'objet de certificat et de limiter le compartiment aux principaux qui en ont besoin. Le bundle contient la clé privée.

Étape 7 : Création du secret du Gestionnaire de Secrets

Conservez les informations d'identification dans un AWS Secrets Manager secret. Pour l'authentification Microsoft Entra App ID, incluez les paires clé-valeur suivantes :

clientId(obligatoire) : l'ID de l'application (client) indiqué à l'étape 1.
clientSecret(obligatoire) : valeur secrète du client indiquée à l'étape 3.
certificatePassword(contrôle d'accès au niveau du document uniquement, recommandé) : le mot de passe que vous avez défini pour le .p12 bundle à l'étape 4. Voir la note qui suit.

Contenu uniquement (aucun contrôle d'accès au niveau du document)


{
    "clientId": "your-client-id",
    "clientSecret": "your-client-secret"
}

Avec contrôle d'accès au niveau du document


{
    "clientId": "your-client-id",
    "clientSecret": "your-client-secret",
    "certificatePassword": "your-certificate-password"
}

Créez le secret avec AWS Command Line Interface :


aws secretsmanager create-secret \
  --name bedrock-onedrive-creds \
  --secret-string file://secret.json

Enregistrez l'ARN secret de la réponse. Vous l'utilisez comme source de donnéessecretArn.

Note

Lorsque le contrôle d'accès au niveau du document est activé, définissez le mot certificatePassword de passe que vous avez utilisé lors de la création du .p12 bundle à l'étape 4. Si vous omettez ce champ, Amazon Bedrock ouvre le bundle en utilisant l'ID client de votre application comme mot de passe. Le bundle doit donc avoir été créé avec l'ID client comme mot de passe. Nous vous recommandons de toujours définir un mot de passe explicite à entropie élevée.

Étape 8 (ACL uniquement) : accorder au rôle de service l'accès au certificat

Votre rôle de service de base de connaissances doit être capable de lire l'objet de certificat depuis Amazon S3. Ajoutez la déclaration suivante à la politique d'autorisation du rôle, en remplaçant le nom du compartiment et la clé par vos valeurs.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3ListCertificateBucket",
            "Effect": "Allow",
            "Action": ["s3:ListBucket"],
            "Resource": ["arn:aws:s3:::your-certificate-bucket"],
            "Condition": {
                "StringEquals": { "aws:ResourceAccount": ["123456789012"] }
            }
        },
        {
            "Sid": "S3GetCertificate",
            "Effect": "Allow",
            "Action": ["s3:GetObject"],
            "Resource": [
                "arn:aws:s3:::your-certificate-bucket/certs/certificate.p12",
                "arn:aws:s3:::your-certificate-bucket/certs/certificate.p12.metadata.json"
            ],
            "Condition": {
                "StringEquals": { "aws:ResourceAccount": ["123456789012"] }
            }
        }
    ]
}

Note

La politique autorise également l'accès en lecture à un .metadata.json fichier facultatif à côté du certificat. Amazon Bedrock n'a pas besoin de ce fichier ; l'inclusion de cette autorisation permet d'éviter les erreurs d'accès en cas de présence d'une telle autorisation.

Si l'objet du certificat est chiffré avec une clé AWS KMS

La commande de téléchargement Étape 6 (ACL uniquement) : chargez le certificat sur Amazon S3 utilise Amazon S3-managed encryption (AES256), qui ne nécessite aucune autorisation supplémentaire. Si vous chiffrez plutôt l'objet du certificat avec le chiffrement côté serveur Amazon S3 à l'aide d'une clé KMS gérée par le client (SSE-KMS), le rôle de service doit également disposer d'une kms:Decrypt autorisation sur cette clé, et la politique de la clé doit autoriser le rôle à l'utiliser. Les objets chiffrés avec la aws/s3 clé AWS gérée ne nécessitent pas cette autorisation supplémentaire.


{
    "Sid": "KmsDecryptCertificate",
    "Effect": "Allow",
    "Action": ["kms:Decrypt"],
    "Resource": ["arn:aws:kms:us-west-2:123456789012:key/your-key-id"]
}

Pour obtenir l'ensemble complet des autorisations relatives aux rôles de service de la base de connaissances, consultezAutorisations d’accès aux sources de données.

Étapes suivantes

Vous disposez désormais des informations d'identification nécessaires pour créer la source de données : l'ARN secret, votre identifiant de locataire et (pour le contrôle d'accès au niveau du document) l'emplacement du certificat sur Amazon S3. Pour créer la source de OneDrive données à l'aide de l'API AWS Management Console ou de l'API, consultezConnecter une source OneDrive de données.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Microsoft OneDrive

Configurer l'authentification OAuth 2.0