最后更新于
最后更新于
Attribute-based access control (ABAC)的优势在于其灵活性和可扩展性。使用ABAC，您可以通过定义基于资源和用户属性（如部门、地理位置或项目名称）的访问控制策略，来动态地控制对资源的访问。这意味着当资源或用户的属性发生变化时，您无需手动更新访问控制策略。例如，如果某个用户的职能从“开发”变更为“项目管理”，他们访问资源的权限可以自动根据其新的角色进行调整。
此外，ABAC能够支持细粒度的访问控制，允许您基于复杂的逻辑和条件为资源定义访问规则，如“只有来自特定IP地址、在工作时间访问的项目经理才允许查看此资源”。这种灵活性使得ABAC特别适合用于需要高度定制访问控制的大型和动态环境中。
传统的RBAC模型根据人员的工作职能定义权限。在Amazon，角色通常指IAM role，是您可以代入的身份。
传统方式是为每个人创建一个user，放在一个group中，group配置不同的策略来实施RBAC。但是作为最佳实践，要求使用最小权限，列出能够访问的特定资源，可以执行的特定操作。那么RBAC模型的缺点是当有新的资源创建出来，必须更新策略来访问这些资源。
假设，你有三个项目，分别为“Heart”， “Sun”和“Lightning”。您为每个项目都创建了组或者IAM role和不同的策略，给人员或者程序分配好后，“Sun”添加了新的资源，比如新的S3存储桶。那么您就需要更新“Sun”的组或者IAM role的策略。否则，Sun的项目组成员就无法访问这个新建的资源。
ABAC更容易规模化管理
管理员不需要不断更新策略来允许访问新的资源。比如，您使用ABAC策略，开发人员和项目资源都是用🏷️标签tag进行标记。当项目需要额外的Amazon资源时，开发人员可以给资源加上标签，然后所有项目组的人员拥有一样的标签就可以看到/更改（可使用的action以策略里定义的为准）这个资源了。（需要policy中condition配置了基于标签进行权限控制）
ABAC需要更少的策略
您不再需要为不同的工作职能创建不同的策略，您只需要创建几个策略，给不同的IAM role，这些策略更易于管理。
使用ABAC，可以实现权限最小化原则
AWS安全最佳实践推荐要实现权限最小化，使用传统的RBAC，你必须创建策略允许访问指定的资源。实际使用时很难落地。使用ABAC只需要标签匹配就可以。如果您使用ABAC，只需要资源的tag与principal的tag匹配，你就可以拥有权限进行操作。不要调整策略，只需要创建资源时带上正确的标签🏷️。
What is ABAC for Amazon?