Какова цель «ресурса» в политике ресурсов AWS?

Question

Как указано в заголовке, какова цель наличия поля ресурса при определении политики ресурса, когда политика ресурса уже будет применяться к конкретному ресурсу.

Например, в этом aws tutorial , следующая политика определяется как прикрепленная к очереди.Какова цель поля resource?

{
 "Version": "2008-10-17",
 "Id": "example-ID",
 "Statement": [
  {
   "Sid": "example-statement-ID",
   "Effect": "Allow",
   "Principal": {
     "AWS": "*"  
   },
   "Action": [
    "SQS:SendMessage"
   ],
   "Resource": "arn:aws:sqs:REGION:ACCOUNT-ID:QUEUENAMEHERE",
   "Condition": {
      "ArnLike": { "aws:SourceArn": "arn:aws:s3:*:*:bucket-name" }
   }
  }
 ]
}

Answer 1

S3 является хорошим примером того, где вам нужно включить оператор ресурса в политику.Допустим, вы хотите иметь место для загрузки в сегменте S3.

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"Upload",
      "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:PutObject"],
      "Resource":["arn:aws:s3:::examplebucket/uploads/*"]
    }
  ]
}

В этих случаях вы действительно не хотите использовать ресурс по умолчанию в корзине, так как он может случайно вызвать глобальный доступ.Лучше убедиться, что пользователь четко понимает, какой доступ разрешен или запрещен.

Но зачем делать это необходимым для политик ресурсов, где он не нужен, как SQS?Для этого давайте углубимся в то, как используются политики ресурсов.

Вы можете предоставить доступ к ресурсам двумя способами:

1. Политики на основе идентификаторов для участников IAM (пользователей и ролей).
2. Политики на основе ресурсов

Важная часть, которую необходимо понять, - это как используются политики ресурсов?Политики ресурсов фактически используются IAM в логике оценки политики для авторизации.Другими словами, ресурсы не несут ответственности за фактическую авторизацию, предоставленную IAM (Identity and Access Management).

Поскольку IAM требует, чтобы у каждого оператора политики был Resource или NotResource, это означает, что службе потребуетсядобавить ресурс при отправке его в IAM, если он отсутствует.Итак, давайте посмотрим на последствия с точки зрения дизайна того, чтобы служба добавила ресурс, если он отсутствует.

1. Службе больше не нужно будет просто проверять правильность политики.
2. Если ресурс отсутствует в операторе, службе необходимо обновить политику перед отправкой в ​​IAM..
3. Теперь существует возможность для двух разных версий политики ресурсов.Тот, который пользователь создал для редактирования, и тот, который был отправлен в IAM.
4. Увеличивает вероятность ошибки пользователя и случайного открытия доступа, прикрепляя политику к неправильному ресурсу.Если мы изменим оператор политики в вопросе, отбросим оператор ресурса и условия, у нас будет довольно открытая политика.Это может быть легко присоединено к неправильному ресурсу, особенно из CLI или terraform.

  {
   "Sid": "example-statement-ID",
   "Effect": "Allow",
   "Principal": {
     "AWS": "*"  
   },
   "Action": [
    "*"
   ]
  }

Примечание. Я ответил на это с точки зрения общего дизайна, основываясь на моем понимании того, как AWS реализует управление доступом.То, как AWS реализовал систему, может немного отличаться, но я сомневаюсь в этом, потому что логику оценки политики действительно нужно оптимизировать для повышения производительности, поэтому лучше делать это в одном сервисе, IAM, а не в каждом сервисе.

Надеюсь, это поможет.

Дополнительное чтение, если вас интересуют подробности логики оценки политики .

. Вы можете запретить доступ 6 способами:

1. Идентификационные данныеПолитика
2. Политики ресурсов
3. Организационные политики, если ваша учетная запись является частью организации
4. Границы разрешений IAM, если установлено
5. Политика предполагаемой сессии, если используется
6. Неявно, если не было разрешающей политики

Вот полный рабочий процесс логики оценки политики IAM.

Answer 2

Существует определенная вами политика.

• Ресурс применяемой политики: A, я не знаю, где вы будете применять это.
• Ресурс в политике: B, arn:aws:sqs:REGION:ACCOUNT-ID:QUEUENAMEHERE

Как только вы примените политику к какому-либо сервису, например ec2, например A, экземпляр сможет выполнять SQS:SendMessage только через ресурс B.А и В совершенно разные.

---

Если вы хотите ограничить разрешение для ресурса A, который не должен иметь доступ к другим ресурсам, но может иметь доступ только к определенным ресурсам, тогда вы должныопределите resource, например, B в политике.

Ваша политика действительна только для этого ресурса B, и это не тот ресурс, который вы применили A.