今までIAMをなんとなく使っていたので、ちゃんと勉強し直して自分（ひいては所属先）の指針について考えを残していきたい。基本的には、2020/02/14にSecurity-JAWSで話した内容の補足だが、時間が足りずに話せなかったSCPについても書いた。

当日のスライドはこちら↓。

Identity-Based Policy と Resource-Based Policyについて

基本的にIdentity-Based (IAM) を念頭に置くのが良いとおもわれる。理由としては主に以下の通り。

クロスアカウント時にも応用が効く
今後やることになるであろうABACにはIdentity-Basedでやるしかない
「誰がどこに何をできる」をResource側でチェックするのが大変

もしResourceが同じアカウントにあるのであれば、明示的なPolicyをResource側に定義しなければ、Identity-Based側の設定が全て反映されるはずだ。自組織内クロスアカウントでの利用は基本的に単一アカウントでの利用より少ないことが予想される。そうであれば引き続きPolicyの主役はIdentity-Basedであり、Resource-based Policyは補助的な役割になるはずだ。

設定の粒度は組織の規模や分業レベル、ひいてはResourceの性質にもよるので一概にはいえない。しかし、自分が所属しがちな組織（~400人）ぐらいでは、とりあえず "Principal": {"AWS": “arn:aws:iam::xxxxx:root"} でクロスアカウント元を指定する以上に厳しい要件があったことはない。

一方、DataDogのような外部サービスや主体からのアクセスがある場合、当然それらのIdentity-Based Policyは管理化にないため必然的にResouce-Baed Policyを充実させるしかない。　

SCP (Service Control Policy)

Service Control PolicyはAWS Organizationレベルで管理できるポリシーのことだ。Organizationレベル

SCPでEffect Denyの用途

Organization全体で統一されたPolicyを、Accountレベルで適用（Attach)する、というのがSCPの一番の効果だと考えられる。 Attachする先を個別のAccountか選択することもできる。全アカウントを指定することも可。いずれもMasterアカウントに対しての効果はない。

Security Hub, Cloud Trail, Config, Guarddutyなど全体に適用させて設定を変更されたくないリソースや、IMDSのようなv2だけに利用を限定さえたいときには、 SCPでEffect Denyすることが有効に思える。Terraformのリソースも容易されているので*1、可視性も担保されるだろう。

SCPでEffect Denyの制限

例えば、EC2:*をDenyするSCPを作ったとしよう。

{
    "Version": "2012-10-17",
    "Statement": [{
            "Sid": "Statement1",
            "Effect": "Deny",
            "Action": ["ec2:*"],
            "Resource": ["*"]
    }]
}

公式ドキュメント*2に書かれている通り、AWS Orgのマスターアカウントには適用されない。つまり、上記のようなEC2へのアクセスをメンバーアカウントでは拒否できるものの、マスターアカウント内はマスターアカウントのIAMあるいはResourceのポリシーがダイレクトに反映される。そのため、やはりマスターアカウントでの操作はなるべく減らす && 最小権限の法則というベストプラクティスは、SCPを有効にしても変えるべきではない。

SCPでEffect Allowを使いたいとき

SCPを有効にするとデフォルトでは、以下のポリシー（FullAWSAccess)がオンになっている。

{
    "Version": "2012-10-17",
    "Statement": [{
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
    }]
}

もし、厳密なホワイトリストポリシーを運用したいのであれば当該SCPをDetachして、明示的に許可したいリソースをAllowするSCPを作成し、Attachすればよい。ただSCP側でAllowされたアクセス制御はDenyと違って適用されない。実際のアクセスを許可するには、AWSメンバーアカウント側のIAMポリシーで許可しなければいけない。

AWS SSO vs IAM Assume RoleでのFederation

IAM Roleと違い、AWS SSOはタグをつけられない。つまり、現時点でABACはできない。また、Permissionに利用するPolicyはAWS SSO内で使いまわしできず、またPermissionと1:1で運用するしかない。将来的にやりたいことと、現時点でやりたいことにおいて、穴があると言わざるをえない。ただポテンシャルはあると思っていて、もしAWSがログイン元をAWS SSOにする内部方針を持っているのであれば、両方の課題解決は時間の問題かもしれない。

今の状況（所属先の状況も含めて）をふまえて個人的に選ぶのであれば、AWS SSOかなあ、とは思っている。 ABACのためのタグポリシーや運用を決めきって広げ終わるくらいには、十分改善されるんじゃないかな。駄目だったらIAM Roleに寄せればいいや、とおもっているくらい。

その他

IMDSに対する所感

難しい。メタデータサービスにアクセスしたいニーズはあると思う。ノードから集中管理サーバーにタグを渡して、ノード一覧画面のラベルとして表示させるOSSは何度かみたことある。管理方法としてはいまいちだが、あるものはあるのだからしょうがない。その場合、iptablesで169.254.169.254へのアクセスを遮断するのよりもいい方法はないものか、とは思う。全インスタンス余計なプロセスを動かさないコンテナとそのタスクにSCPを使ったPolicy制限をまるっとかけるのが現実的では？って思うけどどうだろう。

https://docs.amazonaws.cn/en_us/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html#instance-metadata-v2-how-it-works

*1:https://www.terraform.io/docs/providers/aws/r/organizations_policy.html

*2:https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html