Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Tag-based contrôle d'accès pour les opérations du plan de données Amazon Neptune

Tag-based le contrôle d'accès (TBAC) vous permet d'utiliser AWS des balises de ressources et des balises principales IAM comme conditions dans les politiques IAM et les politiques de contrôle des services (SCP) pour contrôler l'accès aux opérations du plan de données Amazon Neptune. Avec le TBAC, vous pouvez faire en sorte que seuls les principaux dont les balises correspondent aux balises d'un cluster de base de données Neptune puissent effectuer des neptune-db:* actions sur ce cluster, sans énumérer les noms de ressources Amazon (ARN) spécifiques au cluster dans chaque politique.

Le TBAC s'appuie sur le modèle de sécurité existant de Neptune et complète les actions du plan de données de contrôle d'accès basées sur l'action.

Comment le TBAC s'intègre aux couches de sécurité de Neptune

Neptune protège vos données grâce à de multiples mécanismes de sécurité qui se chevauchent. Le TBAC ajoute une couche d'autorisation basée sur les attributs qui fonctionne avec chacun d'entre eux :

Concepts clés du TBAC

Conditions préalables à l'utilisation du TBAC

Avant de pouvoir utiliser le TBAC avec les opérations du plan de données Neptune, vous devez disposer des éléments suivants :

Modèles de politique TBAC

Les modèles suivants montrent les méthodes courantes d'utilisation du TBAC dans les politiques IAM pour les opérations du plan de données Neptune.

Refuser l'accès lorsque les balises principale et ressource ne correspondent pas

Il s'agit du modèle TBAC le plus courant. Il refuse toutes les actions du plan de données Neptune à moins que les balises du principal ne correspondent aux balises de la ressource. Vous pouvez l'appliquer en tant que SCP pour une application à l'échelle de l'organisation ou en tant que politique IAM pour un contrôle ciblé.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNeptuneProjectMismatch",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
        }
      }
    },
    {
      "Sid": "DenyNeptuneDepartmentMismatch",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
        }
      }
    }
  ]
}

Fonctionnement : Chaque instruction utilise une StringNotEquals condition distincte pour une clé de balise unique. Le refus se déclenche indépendamment pour chaque balise : si la Project balise de la ressource ne correspond pas à la Project balise du principal, l'accès est refusé quelle que soit la Department balise. Cela garantit qu'un principal étiqueté avec ne Project=FraudDetection peut accéder qu'aux clusters Neptune également étiquetésProject=FraudDetection, et de même pour. Department

Refuser l'accès lorsque les balises de ressources requises sont manquantes

Ce modèle empêche l'accès aux clusters Neptune qui n'ont pas été correctement balisés, garantissant ainsi que tous les clusters sont inscrits dans le schéma TBAC :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNeptuneMissingProjectTag",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:ResourceTag/Project": "true"
        }
      }
    },
    {
      "Sid": "DenyNeptuneMissingDepartmentTag",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:ResourceTag/Department": "true"
        }
      }
    }
  ]
}

Fonctionnement : La Null condition est considérée comme vraie lorsque la clé de balise spécifiée n'existe pas sur la ressource. Cela oblige tous les clusters Neptune à porter les balises de classification requises avant que le principal puisse y accéder.

Combiner le TBAC avec le contrôle d'accès basé sur l'action

Le TBAC peut être associé à des neptune-db: actions spécifiques pour créer des politiques précises tenant compte des balises :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOnlyForMatchingTags",
      "Effect": "Allow",
      "Action": [
        "neptune-db:ReadDataViaQuery",
        "neptune-db:GetQueryStatus",
        "neptune-db:GetEngineStatus"
      ],
      "Resource": "arn:aws:neptune-db:*:*:*/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
        }
      }
    }
  ]
}

Restriction de langue de requête avec TBAC

Combinez le TBAC avec la clé de neptune-db:QueryLanguage condition pour restreindre à la fois les clusters auxquels un principal peut accéder et les langages de requête qu'il peut utiliser :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOpenCypherOnlyForMatchingProject",
      "Effect": "Allow",
      "Action": [
        "neptune-db:ReadDataViaQuery",
        "neptune-db:WriteDataViaQuery"
      ],
      "Resource": "arn:aws:neptune-db:*:*:*/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",
          "neptune-db:QueryLanguage": "OpenCypher"
        }
      }
    }
  ]
}

Utilisation du TBAC avec les politiques de contrôle des services

Les SCP sont idéaux pour appliquer le TBAC car ils fixent des limites d'autorisation pour l'ensemble d'une unité organisationnelle (UO) ou d'un compte sans qu'il soit nécessaire de modifier les politiques IAM individuelles.

Nous recommandons la stratégie SCP suivante :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNeptuneProjectMismatch",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
        }
      }
    },
    {
      "Sid": "DenyNeptuneDepartmentMismatch",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
        }
      }
    },
    {
      "Sid": "DenyNeptuneMissingProjectTag",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:ResourceTag/Project": "true"
        }
      }
    },
    {
      "Sid": "DenyNeptuneMissingDepartmentTag",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:ResourceTag/Department": "true"
        }
      }
    }
  ]
}

Implémentation du TBAC pour Neptune

Étape 1 : Définissez la taxonomie de vos balises

Choisissez des clés de balise qui représentent les limites de votre organisation. Modèles courants :

Étape 2 : balisez vos clusters de base de données Neptune

Utilisez le AWS CLI pour ajouter les balises de classification requises à vos clusters de base de données Neptune :

aws neptune add-tags-to-resource \
  --resource-name arn:aws:rds:us-east-1:123456789012:cluster:my-neptune-cluster \
  --tags Key=Project,Value=FraudDetection Key=Department,Value=Engineering

Étape 3 : Marquez vos principaux IAM

Utilisez le AWS CLI pour étiqueter les rôles IAM avec les mêmes clés et valeurs que celles utilisées sur vos clusters Neptune. Pour les rôles IAM :

aws iam tag-role \
  --role-name NeptuneAppRole \
  --tags Key=Project,Value=FraudDetection Key=Department,Value=Engineering

Pour les utilisateurs fédérés, transmettez des balises via des balises de SAML/OIDC session à l'aide aws:PrincipalTag des attributs de votre fournisseur d'identité.

Étape 4 : Déployer la politique TBAC

Associez-le en tant que SCP pour une application à l'échelle de l'organisation, ou en tant que politique IAM pour un contrôle ciblé.

Étape 5 : protéger l'intégrité des tags

Limitez les personnes autorisées à modifier les balises sur les ressources Neptune et les principaux IAM :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyTagModification",
      "Effect": "Deny",
      "Action": [
        "rds:AddTagsToResource",
        "rds:RemoveTagsFromResource"
      ],
      "Resource": "*",
      "Condition": {
        "ForAnyValue:StringEquals": {
          "aws:TagKeys": ["Project", "Department"]
        }
      }
    }
  ]
}

Considérations importantes pour le TBAC

Relation avec les fonctionnalités de sécurité existantes de Neptune