【问题标题】:Evaluation logic in IAM policy across multiple json policies跨多个 json 策略的 IAM 策略中的评估逻辑
【发布时间】:2022-01-27 07:12:53
【问题描述】:

对于 IAM 政策,假设有两个政策:

  1. 包含允许访问的单个语句的策略。
  2. 第二个策略,使用单个语句拒绝访问。

例如:

// first document
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ListRead",
            "Effect": "Allow",
            "Action": ["s3:ListAllMyBuckets"],
            "Resource": "*",
            "Principal": { "AWS": "arn:aws:iam::12345:group/davidsgroup" }
        }
    ]
}
// second document
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyS3ListRead",
            "Effect": "Deny",
            "Action": ["s3:ListAllMyBuckets"],
            "Resource": "*",
            "Principal": { "AWS": "arn:aws:iam::12345:user/david" }
        }
    ]
}

如果资源有冲突的陈述,如何确定最终是否会拒绝用户?例如,是按文件顺序吗?原则的粒度?或者当有多个政策文件可能适用于给定用户时,通常如何确定这一点。

【问题讨论】:

  • 注意:第二个文档(“AllowS3ListRead”)中的sid 具有误导性。
  • @jarmod 谢谢——已修复。

标签: amazon-web-services amazon-iam


【解决方案1】:

在最基本的层面上:显式拒绝 > 显式允许 > 隐式拒绝。

在您的示例中,即使明确允许 David 的 IAM 组调用 s3:ListAllMyBuckets,David 的 IAM 用户也被明确拒绝执行相同的操作。在这种情况下,显式拒绝胜过显式允许,大卫被拒绝。

如需深入了解,请参阅Policy evaluation logic

【讨论】:

  • 我明白了,但是如果我将两个语句都放在同一个策略块中,但后面列出了 allow,那会允许吗?
  • 没有。拒绝或允许的位置无关紧要。拒绝 > 允许,无论位置如何。
  • 顺便问一下,这是制定访问策略的常用方法吗?我更习惯于说“SQL 方式”,您可以使用GRANTREVOKE,它只是先进先出(显然)。
  • 深度安全。例如,资源所有者(例如 S3 存储桶)有能力拒绝任何和所有资源消费者(例如 IAM 委托人)的访问,即使是那些已明确允许访问的人。例如,前一个控制的作用是防止后者发生错误或试图提升权限。
  • 我明白了,谢谢你的解释。 AWS IAM 是以任何先前的标准/技术为模型的,还是基本上只是从头开始创建的?
猜你喜欢
  • 2021-10-30
  • 1970-01-01
  • 2022-10-14
  • 1970-01-01
  • 2017-11-26
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-08-25
相关资源
最近更新 更多