AWS IAM Управление ограничением разрешений: другой часто забытый уровень безопасности
14 августа 2025 г.Представьте себе это: это 3 часа ночи, и вы получаете оповещения о том, что кто -то просто удалил что -то важное в вашей производственной инфраструктуре. После некоторого исследования вы обнаружили, что инженер создал роль IAM сАдминистраторПолитика «быстрого исправления» и случайно дала лямбда или EC2 все разрешения.
Звучит знакомо? Если вы работали с AWS, у вас, вероятно, был этот сценарий кошмара, который приходит вам в голову.
Принцип наименьшей привилегии - AWS Security 101, но вот секрет, о котором никто не говорит: даже когда вы следуете за ней, крупные организации с делегированной администрацией все еще могут оказаться в аду разрешения. Вы хотите дать своей команде автономию, но вы также хотите спать по ночам.
Введите границы разрешений IAM - невоспроизводный герой безопасности AWS, который действует как сеть безопасности для ваших разрешений. Думайте о них как о максимальном ограничении скорости для сущностей. Они не дают никому новым полномочиям, но они обязательно предотвратят максимальный уровень проблем с разрешением в будущем
Каковы границы разрешений (и почему вы должны заботиться)?
Граница разрешений - это способ AWS сказать: «У вас могут быть разрешения, но не эти разрешения». Это продвинутая функция IAM, которая устанавливает твердый потолок на то, что когда -либо может сделать роль IAM или пользователь, независимо от того, какие политики вы их прилагаете.
Вот как AWS принимает решение, когда кто -то пытается что -то сделать:
1. Сказывает ли политика IAM «да»?
2. Сказывает ли граница разрешений «да»?
3. Только если оба согласны, происходит действие
Думайте об этом так:
- Политика IAM: «Вот что вы можете сделать»
- Граница разрешений: «Но вы никогда не сможете сделать больше, чем это, даже если обратное определено в политике IAM». Отказ от эффекта на границе всегда будет иметь приоритет над политикой IAM
Реальные сценарии, где это имеет значение
Делегированная дилемма администратора: вы хотите, чтобы ваша команда DevOps создавала роли для своих приложений, но вы не хотите, чтобы они случайно создавали роль, которая может снизить ваш счет AWS или оказывать влияние на вашу безопасность.
Подрядчик CONUNDRUM: что независимый разработчик нуждается в доступе к работе над проектом, но вы бы предпочли не давать им ключи к королевству «на всякий случай».
Ловушка самообслуживания: ваши команды хотят автономии (хорошо!), Но автономия без ограждений-это просто хаос с дополнительными шагами.
Практическая демонстрация: границы разрешений на тестирование
Шаг 1: Создайте свою безопасную сеть
Вот граница разрешений, которая блокирует удаление ковша S3, но да, под капотом - это обычная политика IAM с отрицательным эффектом:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:DeleteBucket"
],
"Effect": "Deny",
"Resource": "*"
}
]
}
Но эта граница не допускает ничего другого. Нам нужно определить разрешение. Например:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:DeleteBucket"
],
"Effect": "Deny",
"Resource": "*"
},
{
"Action": [
"s3:*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
Это означает, что если сама политика позволит «S3: putobject», и она будет сопоставлена с границей разрешения, вам будет разрешено записывать объекты в ведро.
Сохраните это как файл JSON и создайте политику с использованием AWS CLI
$ aws iam create-policy \
--policy-name S3Boundary \
--policy-document file://boundary.json
Это ваша граница - никто с этой границей не может сделать что -либо за пределами S3. В моем примере это роль из функции лямбды
Шаг 2: Прикрепите его к роли
$ aws iam put-role-permissions-boundary \
--role-name MyLambdaRole \
--permissions-boundary arn:aws:iam::123456789012:policy/S3Boundary
Теперь «Mylambdarole» заблокирован в песочнице S3, независимо от того, какие другие политики вы прилагаете к нему.
В консоли AWS вы можете найтиРАЗРЕШЕНИЯ ГраницаЕсли вы откроете роль и немного прокрутите вниз
Давайте попробуем демо с простой функцией Python Lambda, чтобы перечислить все ведра S3:
import json
import boto3
def lambda_handler(event, context):
s3 = boto3.client('s3')
try:
response = s3.list_buckets()
bucket_names = [bucket['Name'] for bucket in response.get('Buckets', [])]
return {
'statusCode': 200,
'body': json.dumps({
'buckets': bucket_names
})
}
except Exception as e:
return {
'statusCode': 500,
'body': json.dumps({'error': str(e)})
}
Эта функция имеет эти разрешения. Я пропущу разрешения CloudWatch по умолчанию, так как в этом примере это не важно:
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
И, очевидно, если я запускаю эту функцию, она сможет перечислить все ведра.
$ aws lambda invoke \
--function-name boundary \
/dev/stdout
{"statusCode": 200, "body": "{\"buckets\": [\"bucket1\", \"bucket2\", \"bucket3\", \"bucket4\"]}"}
Теперь давайте изменим нашу функцию Lambda, чтобы удалить Bucket S3 с именем "Bucket1". Иметь надлежащую демонстрацию границы разрешений
import json
import boto3
def lambda_handler(event, context):
s3 = boto3.client('s3')
bucket_name = "bucket1"
try:
s3.delete_bucket(Bucket=bucket_name)
return {
'statusCode': 200,
'body': json.dumps({
'deleted_bucket': bucket_name
})
}
except Exception as e:
return {
'statusCode': 500,
'body': json.dumps({'error': str(e)})
}
И вызвать эту функцию лямбды:
$ aws lambda invoke \
--function-name boundary \
/dev/stdout
{"statusCode": 500, "body": "{\"error\": \"An error occurred (AccessDenied) when calling the DeleteBucket operation: User: arn:aws:sts::123456789012:assumed-role/MyLambdaRole/MyLambdaFunction is not authorized to perform: s3:DeleteBucket on resource: \\\"arn:aws:s3:::bucket1\\\" because no identity-based policy allows the s3:DeleteBucket action\"}"}
Я не могу сделать это действие, потому что оно ограничено в пределах границы, даже если политика IAM явно допускает "S3:*"
В границе разрешения вы можете объединить любое отрицание и разрешить заявлениям, например, сделать его очень ограничительным и запрещать S3, EC2, Lambda, IAM Deletion:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyS3Deletes",
"Effect": "Deny",
"Action": [
"s3:DeleteBucket"
],
"Resource": "*"
},
{
"Sid": "DenyKMSDeletes",
"Effect": "Deny",
"Action": [
"kms:ScheduleKeyDeletion",
"kms:CancelKeyDeletion",
"kms:DeleteAlias"
],
"Resource": "*"
},
{
"Sid": "DenyEC2Deletes",
"Effect": "Deny",
"Action": [
"ec2:TerminateInstances",
"ec2:DeleteVolume",
"ec2:DeleteSnapshot",
"ec2:DeleteSecurityGroup"
],
"Resource": "*"
},
{
"Sid": "DenyIAMRoleDeletes",
"Effect": "Deny",
"Action": [
"iam:DeleteRole",
"iam:DeleteRolePolicy",
"iam:DetachRolePolicy"
],
"Resource": "*"
},
{
"Sid": "DenyLambdaDeletes",
"Effect": "Deny",
"Action": [
"lambda:DeleteFunction",
"lambda:DeleteAlias"
],
"Resource": "*"
},
{
"Sid": "AllowEverythingElse",
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
И главный вопрос заключается в том, как заставить всех прикрепить границу разрешения, когда они создают роль?
Просто добавьте этот дополнительный оператор к существующим пользователям:
{
"Sid": "DenyCreateRoleWithoutBoundary",
"Effect": "Deny",
"Action": "iam:CreateRole",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/S3Boundary"
}
}
}
Например:
Короче говоря - границы разрешений могут быть прикреплены к ролям на основе ресурсов и идентификации, и помните - в мире облачной безопасности Paranoia не является ошибкой - это функция.
Оригинал