- 追加された行はこの色です。
- 削除された行はこの色です。
#author("2024-01-20T04:54:08+00:00","default:wikiadmin","wikiadmin")
-ユーザー権限管理で契約アカウント一つに対して複数作ることができる。
*自分のAWSアカウントセキュリティ対策 [#n48cdd29]
-ユーザーに権限は付与しない
-IPを制限したユーザー(limited)にたいして、必要なAssumeRoleができるようにする
*CLIでIAMポリシー取得&更新 [#h9cb41e3]
aws --profile assume iam get-policy-version --policy-arn POLICY_ARN --version-id v1
*操作 [#w6ff79eb]
**IAMの一覧 [#u84633f4]
右上の「認証情報」メニューからユーザーを選択すると一覧
*権限 [#q2dc77bc]
とても多いので覚えていられない。デフォルトでは何の権限もないとのこと。
「デフォルト設定では、ユーザーは何もできず、そのユーザーのアクセスキーを参照することすらできません。ユーザーに何かの操作をするアクセス権限を付与する場合には、ユーザーにアクセス権限を追加する(つまり、ポリシーをユーザーに関連付ける)か、ユーザーを該当のアクセス権限を持つグループに追加します。」
**EC2の権限一覧 [#r45cdd63]
http://blog.serverworks.co.jp/tech/2014/02/07/iam-ec2/
**Cloud Watch [#of9f0658]
CloudWatchのAPIを利用するので、「CloudWatch Read Only Access」権限のあるIAM roleをもったインスタンスにしてください。
カスタムメトリックを作成する場合は、CloudWatchの「PutMetricData」を許可するようにします。
http://stk-inc.co.jp/2013/01/aws-cloudwatch-ec2/
*ポリシー [#i6df59a6]
ユーザやグループ、ロール、リソースにアクセス許可を割り当てるには、ポリシーを作成します。ポリシーはアクセス許可を明示的にリスト化したドキュメントです。
**管理ポリシーとインラインポリシー [#cdb3e983]
AWS 管理ポリシーはAWS側が提供しているポリシーでAWS要因で変更される可能性がある。
管理ポリシーとインラインポリシーの違いは、管理ポリシーは複数のエンティティに付与可能。インラインポリシーはその内部のみ。変更管理や複数割り当てができるので管理ポリシーにしておくべし!
|AWS Managed Policy|Amazonが管理しているポリシー。勝手に変更される可能性があるが個人レベルの実験ならこれを割り当てておけ!|
|Customer Managed Policy|ユーザーが自由に設定できる管理ポリシー|
|Inline Policy|個別で設定するポリシー。共有不可能|
3つあるが、定義できることに違いはない。
AWS管理ポリシーにはAmazonS3FullAccessなどサービス名FullAccessなど一目見てわかるものが多い。
**ポリシーの内部の話 [#q04d0efe]
|Effect|AllowかDenyだが、基本Allowしか書かない|
|Action|操作内容。対象:アクションのように記載。S3ならs3:Get*,s3:List*|
|Resource|対象となるリソース。awsの独自表記でS3ならarn:aws:s3:::*|
*IAMユーザー、グループ、ロール [#ff57a1b6]
ユーザーとグループは一般的なものと一緒。ロールはちょっと特殊でEC2インスタンスにアタッチすることによりシークレットキーなしでアクセスできる。
**IPアドレス制限 [#l9531f82]
普通にユーザーにIP制限すると、うまくいかない。内部でCloudFomationとか使っていいてIPが違うから。
https://hacknote.jp/archives/43145/
がうまくいかない!
aws cliでassume roleするには以下のコマンドでキーを払い出すことが必要。
aws sts assume-role --role-arn "ロールARN" --role-session-name AWSCLI-Session --profile=limited
***入り口のIAMロールにIP制限、Admin権限を持つ特権ロールの信頼関係に入り口IAMを指定 [#ye7072ef]
-まずは特定IP以外の全部拒否ポリシー作成 AllowAssumeRoleWithSourceIPRestriction
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SourceIPRestriction",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"xxx.xxx.xxx.xxx/32"
]
}
}
}
]
}
-必要な権限を保持するロールを作成し、上記ユーザーに信頼関係を与える(ここにもIP制限)。principalには先ほど作成したユーザーのARNを
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::699567825067:user/ONAMAE_LIMITED"
},
"Action": "sts:AssumeRole",
"Condition": {
"IpAddress": {
"aws:SourceIp": "157.7.139.75/32"
}
}
}
]
}
-AllowAssumeRoleWithSourceIPRestrictionにAssumeRoleの権限のみ与える
{
"Version": "2012-10-17",
"Statement": [
# ここから
{
"Sid": "AllowAssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::xxxxxxxxxx:role/AssumedAdministratorAccessRole"
},
# ここまで追加
{
"Sid": "SourceIPRestriction",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"xxx.xxx.xxx.xxx/32"
]
}
}
}
]
}
***特定IP以外拒否リスト+許可の組み合わせにする [#jca78d74]
-特定IP以外EC2全部拒否
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowRestriction",
"Action": [
"ec2:*"
],
"Effect": "Deny",
"Resource": [
"*"
],
"Condition": {
"NotIpAddress": {
"aws:SourceIp": "58.0.96.28/32"
}
}
}
]
}
-EC2 許可
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "*"
}
]
}
上記でEC2に関しては、IP制限がきいた。しかしS3などを追加するとそこはどこのIPからもいけてしまう。