对AWS控制台登录强制执行MFA，但不对API调用强制执行 [英] enforce MFA for AWS console login, but not for API calls
问题描述
我希望强制所有IAM用户(本地和远程)启用和激活其MFA设备. 我希望他们所有人都能使MFA能够执行各自的任务.
I am looking to enforce all IAM users(local and remote) to enable and activate their MFA devices. I want them all to enable MFA to do their respective tasks.
我正在尝试以下政策
{
"Effect": "Allow",
"Action": "*",
"Resource": "*",
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}
但是；无论您如何通过控制台或API访问服务，此政策均适用
However; this policy applies irrespective of how you are accessing the services, through console or through APIs
所有用户都完成了很多自动化操作，并且由于没有暗示MFA身份验证，他们的自动化工作也因此中断.
There is a lot of automation done by all users and their automation breaks as MFA authentication was not implied.
第一步，我们希望大家至少启用MFA进行控制台登录；但同样也不应强制他们将MFA用于自动化中使用的API调用.
As a first step, we wish everybody to atleast enables MFA for console login; but the same should not enforce them to use MFA for API calls used in automation.
这可以通过IAM策略实现吗?
Is this achievable through IAM policy?
谢谢
推荐答案
诀窍是取消检查...，而不是只允许aws:MultiFactorAuthPresent为true，否则为false.
The trick is to reverse the check...rather than only allowing if aws:MultiFactorAuthPresent is true, deny if it's false.
以下是自助式MFA管理的文档: http://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html
Here's the doc on self-service MFA management: http://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html
其中建议的完整政策如下:
The full policy suggested in there is:
{
"Version": "2012-10-17",
"Statement":[
{
"Sid": "AllowAllUsersToListAccounts",
"Effect": "Allow",
"Action":[
"iam:ListAccountAliases",
"iam:ListUsers",
"iam:GetAccountSummary"
],
"Resource": "*"
},
{
"Sid": "AllowIndividualUserToSeeAndManageTheirOwnAccountInformation",
"Effect": "Allow",
"Action":[
"iam:ChangePassword",
"iam:CreateAccessKey",
"iam:CreateLoginProfile",
"iam:DeleteAccessKey",
"iam:DeleteLoginProfile",
"iam:GetAccountPasswordPolicy",
"iam:GetLoginProfile",
"iam:ListAccessKeys",
"iam:UpdateAccessKey",
"iam:UpdateLoginProfile",
"iam:ListSigningCertificates",
"iam:DeleteSigningCertificate",
"iam:UpdateSigningCertificate",
"iam:UploadSigningCertificate",
"iam:ListSSHPublicKeys",
"iam:GetSSHPublicKey",
"iam:DeleteSSHPublicKey",
"iam:UpdateSSHPublicKey",
"iam:UploadSSHPublicKey"
],
"Resource": "arn:aws:iam::accountid:user/${aws:username}"
},
{
"Sid": "AllowIndividualUserToListTheirOwnMFA",
"Effect": "Allow",
"Action":[
"iam:ListVirtualMFADevices",
"iam:ListMFADevices"
],
"Resource":[
"arn:aws:iam::accountid:mfa/*",
"arn:aws:iam::accountid:user/${aws:username}"
]
},
{
"Sid": "AllowIndividualUserToManageTheirOwnMFA",
"Effect": "Allow",
"Action":[
"iam:CreateVirtualMFADevice",
"iam:DeactivateMFADevice",
"iam:DeleteVirtualMFADevice",
"iam:RequestSmsMfaRegistration",
"iam:FinalizeSmsMfaRegistration",
"iam:EnableMFADevice",
"iam:ResyncMFADevice"
],
"Resource":[
"arn:aws:iam::accountid:mfa/${aws:username}",
"arn:aws:iam::accountid:user/${aws:username}"
]
},
{
"Sid": "BlockAnyAccessOtherThanAboveUnlessSignedInWithMFA",
"Effect": "Deny",
"NotAction": "iam:*",
"Resource": "*",
"Condition":{
"BoolIfExists":{ "aws:MultiFactorAuthPresent": "false"}
}
}
]
}
最重要的部分是最后一个声明，它拒绝了.如果您将其更改为此:
The most important part is the last statement, which does the deny. If you change it to this:
{
"Sid": "BlockAnyAccessOtherThanAboveUnlessSignedInWithMFA",
"Effect": "Deny",
"NotAction": "iam:*",
"Resource": "*",
"Condition":{
"Bool":{ "aws:MultiFactorAuthPresent": "false"}
}
}
(BoolIfExists更改为Bool)，它将允许IAM访问密钥绕过MFA的要求，同时仍然要求您通过AWS控制台登录时使用MFA.
(BoolIfExists changed to Bool) it will allow IAM access keys to bypass the requirement of MFA, while still requiring you to use MFA when logging in through the AWS Console.
如果您决定使用文档中的完整政策，请当心.请注意，它允许用户创建访问密钥并更改其密码，并且deny子句仅阻止非IAM操作……这意味着，如果在帐户上禁用了MFA，则可以更改用户密码或新的访问密钥可以在没有MFA检查的情况下进行配置，并且如果您对Bool进行了更改，那么这些新的访问密钥将可以在没有MFA的情况下访问用户有权访问的任何内容.即，所有不安全密钥的安全漏洞，其中最有可能造成帐户劫持.
Be careful if you decide to use that full policy from the docs. Note that it allows a user to create access keys and change their password, and the deny clause only blocks non-IAM actions...this means that, if MFA gets disabled on an account, a user's password could be changed or new access keys could be provisioned without an MFA check, and if you've made the Bool change, those new access keys would be able to access anything that the user has permissions for, without MFA. I.E., all of the security vulnerabilities of unsecured keys, with some potential for account hijacking on top.
我建议改用与此类似的政策:
I would suggest using a policy similar to this instead:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAllUsersToListAccounts",
"Effect": "Allow",
"Action": [
"iam:ListAccountAliases",
"iam:ListUsers"
],
"Resource": [
"arn:aws:iam::accountid:user/*"
]
},
{
"Sid": "AllowIndividualUserToSeeTheirAccountInformation",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:GetAccountSummary",
"iam:GetLoginProfile"
],
"Resource": [
"arn:aws:iam::accountid:user/${aws:username}"
]
},
{
"Sid": "AllowIndividualUserToListTheirMFA",
"Effect": "Allow",
"Action": [
"iam:ListVirtualMFADevices",
"iam:ListMFADevices"
],
"Resource": [
"arn:aws:iam::accountid:mfa/*",
"arn:aws:iam::accountid:user/${aws:username}"
]
},
{
"Sid": "AllowIndividualUserToManageThierMFA",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:DeactivateMFADevice",
"iam:DeleteVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ResyncMFADevice"
],
"Resource": [
"arn:aws:iam::accountid:mfa/${aws:username}",
"arn:aws:iam::accountid:user/${aws:username}"
]
},
{
"Sid": "DoNotAllowAnythingOtherThanAboveUnlessMFAd",
"Effect": "Deny",
"NotAction": "iam:*",
"Resource": "*",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
这篇关于对AWS控制台登录强制执行MFA，但不对API调用强制执行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
