AWS/IAM の履歴(No.10)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• AWS/IAM へ行く。
  • 1 (2015-07-21 (火) 02:06:04)
  • 2 (2015-07-21 (火) 02:07:48)
  • 3 (2015-07-21 (火) 06:10:10)
  • 4 (2015-07-22 (水) 01:53:09)
  • 5 (2015-07-22 (水) 09:40:09)
  • 6 (2015-12-16 (水) 15:50:33)
  • 7 (2019-08-12 (月) 15:33:57)
  • 8 (2020-04-03 (金) 20:25:29)
  • 9 (2020-04-04 (土) 11:38:58)
  • 10 (2020-04-04 (土) 14:21:22)
  • 11 (2022-10-14 (金) 13:16:53)

---

• ユーザー権限管理で契約アカウント一つに対して複数作ることができる。

操作†

IAMの一覧†

右上の「認証情報」メニューからユーザーを選択すると一覧

権限†

とても多いので覚えていられない。デフォルトでは何の権限もないとのこと。

「デフォルト設定では、ユーザーは何もできず、そのユーザーのアクセスキーを参照することすらできません。ユーザーに何かの操作をするアクセス権限を付与する場合には、ユーザーにアクセス権限を追加する（つまり、ポリシーをユーザーに関連付ける）か、ユーザーを該当のアクセス権限を持つグループに追加します。」

EC2の権限一覧†

http://blog.serverworks.co.jp/tech/2014/02/07/iam-ec2/

Cloud Watch†

CloudWatchのAPIを利用するので、「CloudWatch Read Only Access」権限のあるIAM roleをもったインスタンスにしてください。 カスタムメトリックを作成する場合は、CloudWatchの「PutMetricData」を許可するようにします。

http://stk-inc.co.jp/2013/01/aws-cloudwatch-ec2/

ポリシー†

ユーザやグループ、ロール、リソースにアクセス許可を割り当てるには、ポリシーを作成します。ポリシーはアクセス許可を明示的にリスト化したドキュメントです。

管理ポリシーとインラインポリシー†

AWS 管理ポリシーはAWS側が提供しているポリシーでAWS要因で変更される可能性がある。 管理ポリシーとインラインポリシーの違いは、管理ポリシーは複数のエンティティに付与可能。インラインポリシーはその内部のみ。変更管理や複数割り当てができるので管理ポリシーにしておくべし！

３つあるが、定義できることに違いはない。 AWS管理ポリシーにはAmazonS3FullAccessなどサービス名FullAccessなど一目見てわかるものが多い。

ポリシーの内部の話†

IAMユーザー、グループ、ロール†

ユーザーとグループは一般的なものと一緒。ロールはちょっと特殊でEC2インスタンスにアタッチすることによりシークレットキーなしでアクセスできる。

IPアドレス制限†

普通にユーザーに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を指定†

• まずは特定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以外拒否リスト+許可の組み合わせにする†

• 特定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からもいけてしまう。