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 sur le 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) afin de contrôler l'accès aux opérations du plan de données Amazon Neptune. Avec 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 contre ce cluster, sans énumérer les Amazon Resource Names (ARN) de cluster spécifiques 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 parallèlement à 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 sur le plan de données Neptune, vous devez disposer des éléments suivants :

Modèles de politique TBAC

Les modèles suivants montrent des manières courantes d'utiliser le TBAC dans les politiques IAM pour les opérations sur le plan de données Neptune.

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

Il s'agit du schéma 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}"
        }
      }
    }
  ]
}

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

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 prend la valeur true lorsque la clé de balise spécifiée n'existe pas sur la ressource. Cela oblige tous les amas de Neptune à porter les étiquettes de classification requises avant qu'un principal puisse y accéder.

Combiner le TBAC avec un 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 TBAC avec la clé de neptune-db:QueryLanguage condition pour limiter à 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 (OU) ou d'un compte sans nécessiter 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 mots-clés 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 : identifiez vos principaux IAM

Utilisez le AWS CLI pour baliser 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éploiement de la politique TBAC

Joignez-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égez l'intégrité des balises

Restreignez les personnes autorisées à modifier les balises sur les ressources Neptune et les principes 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 concernant le TBAC

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