Início / server / Perguntas / 833775
Accepted
ALex_hha
Asked: 2017-02-21 12:11:47 +0800 CST

Como conceder acesso a um SQS a um usuário IAM específico

  • 772

Preciso criar uma política IAM realmente simples e concedê-la a uma fila específica. Preciso conceder acesso (deve ser um acesso total) à fila apenas para um usuário específico do IAM.

Porque no momento, por padrão, todos os usuários do IAM com política AmazonSQSFullAccess / AdministratorAccess podem enviar/ler mensagens para/da fila.

Eu tentei as seguintes políticas, mas sem sucesso

Política 1

{
  "Version": "2012-10-17",
  "Id": "arn:aws:sqs:us-east-1:930XXXXXX332:task-queue/SQSDefaultPolicy",
  "Statement": [
    {
      "Sid": "Sid1487598389851",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "SQS:*",
      "Resource": "arn:aws:sqs:us-east-1:930XXXXXX332:task-queue",
      "Condition": {
        "ArnNotEquals": {
          "aws:SourceArn": "arn:aws:iam::930XXXXXX332:user/test-sqs"
        }
      }
    },
    {
      "Sid": "Sid1487599825058",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::930XXXXXX332:user/test-sqs"
      },
      "Action": "SQS:*",
      "Resource": "arn:aws:sqs:us-east-1:930XXXXXX332:task-queue"
    }
  ]
}

Política 2 (o mesmo que acima, mas tentei outra condição)

"Condition": {
        "NotPrincipal": { 
             "AWS": "arn:aws:iam::930XXXXXX332:user/test-sqs" 
        }
  }

Em outras palavras - eu preciso obter algo como o seguinte

Allow: user1, user2
Deny: *

É possível de alguma forma?

No momento, tenho que especificar explicitamente cada usuário no efeito Negar. E isso é extremamente inconveniente

amazon-web-services

2 respostas

  1. Best Answer

    Finalmente encontrei uma solução alternativa. Com a política abaixo funciona como esperado

    {
  "Version": "2012-10-17",
  "Id": "arn:aws:sqs:us-east-1:930XXXXXX332:test-queue",
  "Statement": [
    {
      "Sid": "Sid1472529596416",
      "Effect": "Deny",
      "NotPrincipal": {
        "AWS": [
          "arn:aws:iam::930XXXXXX332:user/test-sqs",
          "arn:aws:iam::930XXXXXX332:root"
        ]
      },
      "Action": "SQS:*",
      "Resource": "arn:aws:sqs:us-east-1:930XXXXXX332:test-queue"
    }
  ]
}

    A parte crucial é - você precisa especificar explicitamente a conta root . Sem ele - não funcionaria de jeito nenhum. Quanto a mim, é alguma mágica da AWS :) Mas pode ser que alguém possa esclarecer a situação.

    Atualização 01.03.2017 Parece que encontrei a descrição de tal comportamento - http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#NotPrincipal

    No exemplo a seguir, todos os principais, exceto o usuário chamado Bob na conta da AWS 44445556666, têm acesso explicitamente negado a um recurso. Observe que, para obter o efeito pretendido, o elemento NotPrincipal contém o ARN do usuário Bob e da conta da AWS à qual Bob pertence (arn:aws:iam::444455556666:root). Se o elemento NotPrincipal contivesse apenas o ARN de Bob, o efeito da política seria negar explicitamente o acesso à conta da AWS que contém o usuário Bob.

    Um usuário não pode ter mais permissões do que sua conta pai, portanto, se o acesso à conta de Bob for explicitamente negado, Bob também não poderá acessar o recurso.

    "Effect": "Deny",
"NotPrincipal": {
  "AWS": [
    "arn:aws:iam::444455556666:user/Bob",
    "arn:aws:iam::444455556666:root"
  ]
}

    Combinar Deny e NotPrincipal é a única vez que a ordem na qual a AWS avalia os principais faz diferença

    • 4

  2. A primeira parte do código inicial falha porque a condição é verificada novamente no recurso Arn, portanto, você basicamente nega o acesso a todas as filas. A segunda parte deve funcionar, mas uma negação de acesso explícita sempre tem precedência.

    A "política 2" está errada, pois novamente você daria acesso a todos, menos ao usuário ao qual você precisa dar acesso. Mas a negação global que você usou acima ainda tem precedência, portanto, nenhum efeito.

    Acho que seu problema está na base de suas configurações IAM atuais - você nunca deveria ter dado um acesso tão amplo aos seus sistemas a todos os seus usuários. O IAM funciona com base em "permita o que você precisa estritamente", o que é melhor para a segurança. Em vez disso, você se envolveu em um "negar tudo, exceto o que você precisa", que dificilmente pode ser mantido no IAM por causa das declarações de "negação" sempre vencendo.

    A solução alternativa por enquanto é o que você fez - aplicar uma política de negação a um grupo e aplicar esse grupo a todos os usuários que não deveriam ter acesso. Mas, à medida que mais filas podem ser criadas, você se encontrará em um loop interminável de políticas de negação em que precisará definir explicitamente os nomes de todas as suas filas nas políticas de negação. E ainda - isso será seguro ou fará sentido? Você disse que deu a muitos usuários uma função de administrador - se eles podem modificar suas políticas IAM, eles podem fazer tudo - o cloudtrail pode dizer o que aconteceu, mas não trará seus dados de volta.

    Eu sugiro seriamente que você adote uma abordagem diferente e defina políticas muito mais limitadas para seus usuários. Crie políticas extras conforme necessário e torne-as cumulativas, anexe-as a grupos e dos grupos aos usuários. Aproveite o curinga nos valores de arn para eventualmente criar namespaces "reservados" para seus recursos com acesso mais restrito.

    • 0

relate perguntas