Esempi di policy di autorizzazione per AWS Secrets Manager

Una policy di autorizzazione è il testo strutturato JSON. Vedere Struttura dei documenti di policy JSON

Le policy di autorizzazione associati alle risorse e alle identità sono molto simili. Alcuni elementi inclusi in una policy per l'accesso ai segreti includono:

• Principal: a chi concedere l'accesso. Vedere Specifica di un principale nel manuale utente IAM. Quando si allega una policy a un'identità, non si include un elemento Principal nella policy.

• Action: cosa possono fare. Per informazioni, consultare Operazioni di Secrets Manager.

• Resource: a quali segreti possono accedere. Per informazioni, consultare Risorse di Secrets Manager.

  Il carattere jolly (*) ha un significato diverso in base a cui si collega la policy:

  • In una policy collegata a un segreto, * significa che la policy si applica a questo segreto.

  • In un criterio collegato a un'identità, * significa che il criterio si applica a tutte le risorse, inclusi i segreti, nell'account.

Per collegare una policy a un segreto, consultare Allegare una policy di autorizzazione a un segreto AWS Secrets Manager.

Per collegare una policy a un'identità, consultare Allegare un policy di autorizzazione a un'identità.

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 Allegare una policy di autorizzazione a un segreto AWS Secrets Manager e Allegare un policy di autorizzazione a un'identità.

Negli esempi seguenti vengono illustrati due modi differenti per concedere l'accesso a un segreto. Il primo esempio è una policy basata su risorse che possono essere collegate a un segreto. Questo esempio è utile quando si desidera concedere l'accesso a un singolo segreto a più utenti o ruoli. Il secondo esempio è un criterio basato sull'identità che è possibile associare a un utente o a un ruolo in IAM. Questo esempio è utile quando si desidera concedere l'accesso a un gruppo IAM. Per concedere l'autorizzazione a recuperare un gruppo di segreti in una chiamata API batch, consulta Autorizzazione per il recupero di un gruppo di valori segreti in un batch.

Esempio Leggi un segreto (allega un segreto)

È possibile concedere l'accesso a un segreto allegando a tale segreto la policy seguente. Per utilizzare questa policy, consultare Allegare una policy di autorizzazione a un segreto AWS Secrets Manager.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::AccountId:role/EC2RoleToAccessSecrets"
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*"
    }
  ]
}

Esempio Leggi un segreto (allega un'identità)

È possibile concedere l'accesso a un segreto allegando a un'identità la policy seguente. Per utilizzare questa policy, consultare Allegare un policy di autorizzazione a un'identità. Se si allega questa policy al ruolo EC2RoletoAccessSecrets, concede le stesse autorizzazioni della policy precedente.

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

Esempio Leggere un segreto crittografato utilizzando una chiave gestita dal cliente (allegarla all'identità)

Se un segreto viene crittografato utilizzando una chiave gestita dal cliente, puoi concedere l'accesso per leggere il segreto allegando la seguente policy a un'identità. Per utilizzare questa policy, consultare Allegare un policy di autorizzazione a un'identità.

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

Autorizzazione per il recupero di un gruppo di valori segreti in un batch

Esempio Leggi un gruppo di segreti in un batch (allega all'identità)

Allegando a un'identità la policy seguente, è possibile concedere l'accesso per recuperare un gruppo di segreti in una chiamata API batch. La policy limita il chiamante in modo che possa recuperare solo i segreti specificati da SecretARN1, SecretARN2 e SecretARN3 anche se la chiamata batch include altri segreti. Se il chiamante richiede anche altri segreti nella chiamata API batch, Secrets Manager non li restituirà. Per ulteriori informazioni, consulta Recupera un gruppo di segreti in un batch da AWS Secrets Manager. Per utilizzare questa policy, consultare Allegare un policy di autorizzazione a un'identità.

{
  "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 (allega all'identità)

La policy seguente concede l'accesso al recupero di tutti i segreti con un nome che inizia con "TestEnv/". Per utilizzare questa policy, consultare Allegare un policy di autorizzazione a un'identità.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "arn:aws:secretsmanager:Region:AccountId:secret:TestEnv/*"
  }
}

Esempio Accedi ai metadati su tutti i segreti (allegati all'identità)

Le seguenti sovvenzioni DescribeSecret e le autorizzazioni che iniziano con List: ListSecrets e ListSecretVersionIds. Per utilizzare questa policy, consultare Allegare un policy di autorizzazione a un'identità.

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

Esempio Corrispondenza al nome segreto (allega all'identità)

La policy seguente concede tutte le autorizzazioni di Secrets Manager per un segreto, per nome. Per utilizzare questa policy, consultare Allegare un policy di autorizzazione a un'identità.

Per abbinare un nome segreto, creare l'ARN per il segreto mettendo insieme la regione, l'ID dell'Account, il nome segreto e il carattere jolly (?) per abbinare singoli caratteri casuali. Secrets Manager aggiunge sei caratteri casuali ai nomi segreti come parte del loro ARN, per poter utilizzare questo carattere jolly per abbinare tali caratteri. 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".

Perché puoi prevedere tutte le parti dell'ARN di un segreto eccetto i 6 caratteri casuali, usando il carattere jolly '??????' la sintassi ti consente di concedere le autorizzazioni in modo sicuro 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, allegare una policy di autorizzazioni a un gruppo IAM a cui appartiene l'utente. Consultare Gruppi di utenti IAM.

Esempio Creare segreti (allegati all'identità)

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

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

Esempio: autorizzazioni e VPC

Se è necessario accedere a Secrets Manager da un VPC, è possibile assicurarsi che le richieste a Secrets Manager provengano dal VPC includendo una condizione nelle policy di autorizzazione. Per ulteriori informazioni, consultare Condizioni dell'endpoint VPC e Utilizzo di un endpoint VPC AWS Secrets Manager.

Assicurati che le richieste di accesso al segreto da altri AWS provengono anche dal VPC, altrimenti questa policy negherà loro l'accesso.

Esempio Richiedere che le richieste vengano inviate tramite un endpoint VPC (collegamento a segreto)

La seguente policy consente all'utente di eseguire operazioni Secret Manager solo quando la richiesta proviene tramite l'endpoint VPC specificato vpce-1234a5678b9012c. Per utilizzare questa policy, consultare Allegare una policy di autorizzazione a un segreto AWS Secrets Manager.

{
  "Id": "example-policy-1",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictGetSecretValueoperation",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpce": "vpce-1234a5678b9012c"
        }
      }
    }
  ]
}

Esempio Richiedere che le richieste provengano da un VPC (allegati al segreto)

I seguenti comandi della policy consentono di creare e gestire i segreti solo quando la loro provenienza è vpc-12345678. Inoltre, la policy consente le operazioni che utilizzano il valore del segreto crittografato solo quando le richieste provengono da vpc-2b2b2b2b. Puoi usare una policy come questa se esegui un'applicazione in un VPC, ma utilizzi un secondo VPC separato per le funzioni di gestione. Per utilizzare questa policy, consultare Allegare una policy di autorizzazione a un segreto AWS Secrets Manager.

{
  "Id": "example-policy-2",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAdministrativeActionsfromONLYvpc-12345678",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "secretsmanager:Create*",
        "secretsmanager:Put*",
        "secretsmanager:Update*",
        "secretsmanager:Delete*",
        "secretsmanager:Restore*",
        "secretsmanager:RotateSecret",
        "secretsmanager:CancelRotate*",
        "secretsmanager:TagResource",
        "secretsmanager:UntagResource"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpc": "vpc-12345678"
        }
      }
    },
    {
      "Sid": "AllowSecretValueAccessfromONLYvpc-2b2b2b2b",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpc": "vpc-2b2b2b2b"
        }
      }
    }
  ]
}

Esempio: Controllare l'accesso ai segreti utilizzando i tag

Puoi utilizzare i tag per controllare l'accesso ai segreti. Usare i tag per controllare le autorizzazioni è utile in ambienti soggetti a una rapida crescita e aiuta in situazioni in cui la gestione delle policy diventa complicata. Una strategia è quella di allegare tag ai segreti e quindi concedere le autorizzazioni a un'identità quando un segreto ha un tag specifico.

Esempio Consenti l'accesso ai segreti con un tag specifico (allegata a un'identità)

La policy seguente consente DescribeSecret sui segreti con un tag con la chiave "ServerName (Nome server)" e il valore "ServerABC". Per utilizzare questa policy, consultare Allegare un policy di autorizzazione a un'identità.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "secretsmanager:DescribeSecret",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "secretsmanager:ResourceTag/ServerName": "ServerABC"
      }
    }
  }
}

Esempio: Limitare l'accesso alle identità con tag che corrispondono ai tag dei segreti

Una strategia è quella di allegare tag sia ai segreti che alle identità IAM. Quindi creare policy di autorizzazioni per consentire operazioni quando il tag dell'identità corrisponde al tag del segreto. Per un tutorial completo, consultare Definire le autorizzazioni per accedere ai segreti in base ai tag.

Utilizzare i tag per controllare le autorizzazioni è utile in ambienti soggetti a una rapida crescita e aiuta in situazioni in cui la gestione delle policy diventa complicata. Per ulteriori informazioni, consulta Che cos'è ABAC per AWS?

Esempio Consentire l'accesso a ruoli con gli stessi tag dei segreti (allegati a un segreto)

La seguente policy garantisce GetSecretValue all'account 123456789012 solo se il tag AccessProject ha lo stesso valore per il segreto e il ruolo. Per utilizzare questa policy, consultare Allegare una policy di autorizzazione a un segreto AWS Secrets Manager.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "AWS": "123456789012"
    },
    "Condition": {
      "StringEquals": {
        "aws:ResourceTag/AccessProject": "${ aws:PrincipalTag/AccessProject }"
      }
    },
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "*"
  }
}
      

Esempio: Principale del servizio

Se la policy sulle risorse collegata al tuo segreto include un principale del servizio AWS, ti consigliamo di utilizzare le chiavi di condizione globali aws:SourceArn e aws:SourceAccount. I valori ARN e account sono inclusi nel contesto di autorizzazione solo quando una richiesta arriva a Secrets Manager da un altro servizio AWS. Questa combinazione di condizioni evita un potenziale confused deputy scenario (scenario "deputy confused").

Se una risorsa ARN include caratteri non consentiti in una policy di risorse, non potrai utilizzare l'ARN di tale risorsa nel valore della chiave di condizione aws:SourceArn. Devi invece utilizzare la chiave di condizione aws:SourceAccount. Per ulteriori informazioni, consulta Requisiti IAM.

I principali del servizio in genere non vengono utilizzati come principali in un criterio collegato a un segreto, ma alcuni servizi AWS lo richiedono. Per informazioni sulle policy delle risorse che un servizio richiede di allegare a un segreto, consultare la documentazione del servizio.

Esempio Consenti a un servizio di accedere a un segreto utilizzando un principale di servizio (collegamento a un segreto)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "service-name.amazonaws.com"
        ]
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "aws:sourceArn": "arn:aws:service-name::123456789012:*"
        },
        "StringEquals": {
          "aws:sourceAccount": "123456789012"
        }
      }

    }
  ]
}