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

Question

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

Como 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 eu tentei outra condição)

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

Em outras palavras, preciso obter algo parecido com o seguinte

Allow: user1, user2
Deny: *

É possível?

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

    

Answer 1

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ê tem que especificar explicitamente a conta root . Sem isso - não funcionaria de todo. Quanto a mim, é uma 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 - link

No exemplo a seguir, todos os principais, exceto o usuário chamado Bob na conta AWS 444455556666, têm o acesso explicitamente negado a um recurso. Observe que para alcançar 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 continha 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 a conta de Bob tiver o acesso explicitamente negado, ele 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 em que a ordem em que a AWS avalia os principais faz a diferença

    

Answer 2

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

A "política 2" está errada, pois você daria acesso a todos, exceto ao usuário para o qual 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 das configurações atuais do seu IAM - você nunca deve ter dado acesso tão amplo aos seus sistemas a todos os usuários. O IAM funciona com base em "permitir o que você precisa estritamente", o que é melhor para a segurança. Em vez disso, você se envolveu em um "negar tudo, menos o que você precisa", o que dificilmente pode ser mantido no IAM por causa das declarações "negar" sempre ganhando.

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 devem ter acesso. Mas, à medida que mais filas forem criadas, você se encontrará em um ciclo infinito 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 você deu a muitos usuários uma função de administrador - se eles podem modificar suas políticas do IAM, eles podem fazer tudo - o cloudtrail pode informar o que aconteceu, mas não trará seus dados de volta.

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 faça com que elas sejam cumulativas. Anexe-as aos grupos e dos grupos aos usuários. Aproveite o curinga nos valores arn para, eventualmente, criar namespaces "reservados" para seus recursos com acesso mais restrito.