Policy basate su identità - AWS Secrets Manager
Esempio: Autorizzazione per recuperare valori segreti individualiEsempio: autorizzazione a leggere e descrivere singoli segretiEsempio: autorizzazione a recuperare un gruppo di valori segreti in un batchEsempio: il carattere jollyEsempio: Autorizzazione per creare segretiEsempio: nega una AWS KMS chiave specifica per crittografare i segreti

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Policy basate su identità

Puoi allegare politiche di autorizzazione alle IAMidentità: utenti, gruppi di utenti e ruoli. In una policy basata sull'identità, specifichi a quali segreti può accedere l'identità e le azioni che l'identità può eseguire sui segreti. Per ulteriori informazioni, consulta Aggiungere e rimuovere le autorizzazioni di IAM identità.

Puoi concedere autorizzazioni a un ruolo che rappresenta un'applicazione o un utente in un altro servizio. Ad esempio, un'applicazione in esecuzione su un'EC2istanza Amazon potrebbe richiedere l'accesso a un database. Puoi creare un IAM ruolo collegato al profilo dell'EC2istanza e quindi utilizzare una politica di autorizzazioni per concedere al ruolo l'accesso al segreto che contiene le credenziali per il database. Per ulteriori informazioni, consulta Usare un IAM ruolo per concedere le autorizzazioni alle applicazioni in esecuzione su EC2 istanze Amazon. Altri servizi a cui puoi assegnare ruoli includono Amazon Redshift e AWS LambdaAmazon. ECS

Puoi anche concedere autorizzazioni agli utenti autenticati da un sistema di identità diverso da. IAM Ad esempio, puoi associare IAM ruoli agli utenti di app mobili che accedono con Amazon Cognito. Il ruolo concede all'app le credenziali provvisorie con le autorizzazioni nella policy di autorizzazioni del ruolo. È quindi possibile utilizzare una policy di autorizzazione per concedere al ruolo l'accesso al segreto. Per ulteriori informazioni, consulta Provider di identità e federazione.

Si possono utilizzare policy basate su identità per:

  • Concedi un accesso alle identità a più segreti.

  • Controllare chi può creare nuovi segreti e chi può accedere a segreti che non sono ancora stati creati.

  • Concedi a un IAM gruppo l'accesso ai segreti.

Esempio: Autorizzazione per recuperare valori segreti individuali

Per concedere il permesso di recuperare valori segreti, è possibile allegare policy a segreti o identità. Per informazioni sul tipo di criterio da utilizzare, vedere Policy basate su identità e policy basate su risorse. Per informazioni sul collegamento di una policy a un'identità, vedere Policy basate su risorse e Policy basate su identità.

Questo esempio è utile quando si desidera concedere l'accesso a un IAM gruppo. Per concedere l'autorizzazione a recuperare un gruppo di segreti in una API chiamata batch, vedereEsempio: autorizzazione a recuperare un gruppo di valori segreti in un batch.

Esempio Leggi un segreto crittografato utilizzando una chiave gestita dal cliente

Se un segreto è crittografato utilizzando una chiave gestita dal cliente, puoi concedere l'accesso alla lettura del segreto allegando la seguente politica a un'identità. \

{
"Version": "2012-10-17",
"Statement": [
{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "SecretARN"
},
{
  "Effect": "Allow",
  "Action": "kms:Decrypt",
  "Resource": "KMSKeyARN"
}
]
}

Esempio: autorizzazione a leggere e descrivere singoli segreti

Esempio Leggi e descrivi un segreto

È possibile concedere l'accesso a un segreto allegando a un'identità la policy seguente.

{
"Version": "2012-10-17",
"Statement": [
  {
    "Effect": "Allow",
    "Action": [
      "secretsmanager:GetSecretValue",
      "secretsmanager:DescribeSecret"
      ],
    "Resource": "SecretARN"
  }
]
}

Esempio: autorizzazione a recuperare un gruppo di valori segreti in un batch

Esempio Leggi un gruppo di segreti in un batch

È possibile concedere l'accesso per recuperare un gruppo di segreti in una API chiamata batch allegando la seguente politica a un'identità. La politica limita il chiamante in modo che possa recuperare solo i segreti specificati da SecretARN1, SecretARN2e SecretARN3, anche se la chiamata batch include altri segreti. Se il chiamante richiede anche altri segreti nella API chiamata batch, Secrets Manager non li restituirà. Per ulteriori informazioni, vedereBatchGetSecretValue. . 

{
"Version": "2012-10-17",
"Statement": [
{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:BatchGetSecretValue",
    "secretsmanager:ListSecrets"
  ],
  "Resource": "*"
},
{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:GetSecretValue"
  ],
  "Resource": [
    "SecretARN1",
    "SecretARN2",
    "SecretARN3"
    ]
}
]
}

Esempio: il carattere jolly

È possibile utilizzare caratteri jolly per includere un set di valori in un elemento della policy.

Esempio Accedi a tutti i segreti di un percorso

La seguente politica consente l'accesso per recuperare tutti i segreti il cui nome inizia con»TestEnv/".

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:Region:AccountId:secret:TestEnv/*"
}
}
Esempio Accedi ai metadati relativi a tutti i segreti

Le seguenti sovvenzioni DescribeSecret e le autorizzazioni che iniziano con List: ListSecrets e ListSecretVersionIds.

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
  "secretsmanager:DescribeSecret",
  "secretsmanager:List*"
],
"Resource": "*"
}
}
Esempio Corrisponde al nome segreto

La policy seguente concede tutte le autorizzazioni di Secrets Manager per un segreto, per nome. Per utilizzare questa policy, consultare Policy basate su identità.

Per abbinare un nome segreto, crei il ARN nome del segreto mettendo insieme la regione, l'ID account, il nome segreto e il carattere jolly (?) per abbinare singoli caratteri casuali. Secrets Manager aggiunge sei caratteri casuali ai nomi segreti come parte dei loro nomiARN, quindi puoi usare questo jolly per abbinare quei personaggi. Se si utilizza la sintassi "another_secret_name-*", Secret Manager individua la corrispondenza non solo del determinato segreto con i 6 caratteri casuali, ma anche di "another_secret_name-<anything-here>a1b2c3".

Poiché è possibile prevedere tutte le parti ARN di un segreto tranne i 6 caratteri casuali, l'utilizzo della '??????' sintassi dei caratteri jolly consente di concedere in modo sicuro le autorizzazioni a un segreto che non esiste ancora. Tuttavia, tieni presente che, se elimini il segreto e lo ricrei con lo stesso nome, l'utente riceve automaticamente l'autorizzazione per il nuovo segreto, anche se i 6 caratteri sono cambiati. 

{
"Version": "2012-10-17",
"Statement": [
{
  "Effect": "Allow",
  "Action": "secretsmanager:*",
  "Resource": [
    "arn:aws:secretsmanager:Region:AccountId:secret:a_specific_secret_name-a1b2c3",
    "arn:aws:secretsmanager:Region:AccountId:secret:another_secret_name-??????"
  ]
}
]
}

Esempio: Autorizzazione per creare segreti

Per concedere a un utente le autorizzazioni per creare un segreto, ti consigliamo di allegare una politica di autorizzazione a un gruppo a cui appartiene l'utente. IAM Vedi gruppi di IAMutenti.

Esempio Crea segreti

La policy seguente concede l'autorizzazione per creare segreti e visualizzare un elenco di segreti. Per utilizzare questa policy, consultare Policy basate su identità.

{
"Version": "2012-10-17",
"Statement": [
{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:CreateSecret",
    "secretsmanager:ListSecrets"
  ],
  "Resource": "*"
}
]
}

Esempio: nega una AWS KMS chiave specifica per crittografare i segreti

Importante

Per negare una chiave gestita dal cliente, ti consigliamo di limitare l'accesso utilizzando una politica o una concessione di chiavi. Per ulteriori informazioni, consulta Autenticazione e controllo degli accessi AWS KMS nella Guida per gli AWS Key Management Service sviluppatori.

Esempio Nega la chiave AWS gestita aws/secretsmanager

La seguente politica mostra come negare l'uso della chiave AWS gestita aws/secretsmanager per la creazione o l'aggiornamento di segreti. Ciò significa che i segreti devono essere crittografati utilizzando una chiave gestita dal cliente. Se la aws/secretsmanager chiave esiste, è necessario includere anche il relativo ID. Includi anche la stringa vuota perché Secrets Manager la interpreta come chiave AWS aws/secretsmanager gestita. La seconda dichiarazione nega le richieste di creazione di segreti che non includono una KMS chiave, perché Secrets Manager la interpreta come chiave AWS gestita. aws/secretsmanager

{
"Version": "2012-10-17",
"Statement": [
  {
      "Sid": "RequireCustomerManagedKeysOnSecrets",
      "Effect": "Deny",
      "Action": [
          "secretsmanager:CreateSecret",
          "secretsmanager:UpdateSecret"
      ],
      "Resource": "*",
      "Condition": {
          "ForAnyValue:StringLikeIfExists": {
              "secretsmanager:KmsKeyId": [
                  "*alias/aws/secretsmanager",
                  "*<key_ID_of_the_AWS_managed_key>",
                  ""
              ]
          }
      }
  },
  {
      "Sid": "RequireKmsKeyIdParameterOnCreate",
      "Effect": "Deny",
      "Action": "secretsmanager:CreateSecret",
      "Resource": "*",
      "Condition": {
          "Null": {
              "secretsmanager:KmsKeyId": "true"
          }
      }
  }
]
}