🫥

IAM、セキュリティ

2023/10/15に公開

IAM

AWSが提供する権限管理サービス

フル権限(rootユーザー)

→ rootユーザーのこと
クレジットカードの情報など重要な情報を管理しているので基本的には利用しないユーザー

IAMユーザー

個別に払い出すユーザー(IAMユーザー)
人だけに払い出すのではなく、プログラムに対してもIAMを払い出すこともできる

プログラムによるアクセス

IAMでアクセスキーID&シークレットアクセスキー発行するとプログラムがAWSを利用することが可能になる
→ ローカルPCなど、どこからでもアクセス/制御/管理することができる
→ ローカルからCLIを通すことで作成や削除などの操作が可能
→ GitHubには絶対に外部に公開しないように(不正アクセスの原因になりかねない)

マネジメントコンソールアクセス

IAMユーザーを作成して、パスワード発行することでAWSを利用できるようになる

IAMグループ

IAMをグループ化したもの
1ユーザー(IAM)は複数のグループに所属可能になる。
基本的にはユーザーに直接権限を付与したりはすることがない。
グループに対して権限管理を行っていく
IAMグループはプリンシパルとして認識されない

※プリンシパル
AWS リソースに対してアクションまたはオペレーションをリクエストできる側のこと

参考) https://dev.classmethod.jp/articles/re-introduction-2022-aws-iam/

IAMポリシー

JSON形式で権限操作を表したもの
認証主体(Identity)をプリンシパルにアタッチすることで権限を付与できる

AWS管理ポリシー

あらかじめAWSが用意したものポリシーのこと

カスタマー管理ポリシー

ユーザーがポリシーをカスタマイズすることができるポリシーのこと作成
※ 一から作ることもできるがポリシージェネレーターを使ってポリシーをGUIで書くことができる

クロスアカウントの場合など

操作する側と操作される側の設定が必要(これをリソースベースポリシー)

リソースベースのポリシーは、AWS サービス内のリソースに紐づくタイプのポリシーです。このポリシーは、リソースに対してアタッチされ、アタッチされたリソースが「どんな時に、どのリソースに、どんなアクションを、誰に」実行される事が可能かを設定できます。

IAMロール

役割などという意味でIAMロールはポリシーをまとめたもの
誰がこのロールになること(使用)ができるかを決めていく

https://aws.amazon.com/jp/builders-flash/202303/learn-iam-role/?awsf.filter-name=*all

Switchロール

デフォルトの権限から入れ替えて(ロールを一時的に付与)操作できるようにすることができる

簡単名称まとめ

名称 対象
リソース(割り当てるもの) IAMユーザー/グループ IAMロール IAMポリシー
アイデンティティ(割り当てられるもの) IAMユーザー/グループ IAMロール
エンティティ(認証に使用するもの) IAMユーザー IAMロール フェデレーションユーザー
プリンシパル(リクエストを出すもの) IAMユーザー IAMロール フェデレーションユーザー AWSリソース

ポリシー詳細

要素 説明
Sid 任意の名前のようなもの。このポリシーの説明などを記述
Effect 許可(Allow)/拒否(Deny)を記述
Principal アクセスする情報記述
Action 操作内容を記述
Resource どのAWSリソースに適用するかを記述する。
Condition どういった条件下(時間やソースIPアドレスなど)でポリシーを適用するのかを記述する。

Identityベース

認証主体にアタッチするポリシー
プリンシパルをわざわざ書かない

リソースベース
操作される側にアタッチするポリシー

以下サンプル

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EC2FullAccess",
	    "Principal": { "AWS": "123456789012" },
            "Effect": "Allow",
            "Action": "ec2:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalArn": "arn:aws:iam::123456789123:user/くるま-user"
            }
        }
    ]
}

AWS Directory Service

Active Directory
→ ユーザー名やパスワードなどの属性情報を管理する(サーバのことをドメインコントローラー)

MSAD(Managed Microsoft AD)

自力でADを作成しなくとも、AWSの管理下でのADを利用することができる。
⇨ フルマネージドサービスなので運用不可が少なくて済む

既存ADと信頼関係を結ぶことができる
なのでユーザー情報などを全て一から設定するのようなことはしなくても良い

MSAD自体にRDPで接続できない(設定)ので別途クライアント側にWindowsServerが必要
そこからMSADを利用する形になる

https://dev.classmethod.jp/articles/management-server-for-aws-managed-microsoft-ad/

AD Connector

ADそのものではく、既存ADを繋ぐプロキシのようなもの
オンプレから WorkSpaces使いたいなどの要件があった場合AD Connectorを利用することでハブ的な役割で既存ADを使った運用ができる

SimpleAD

フルマネージドのADサービス
アカウント、グループ管理 グループポリシーの適用
Linux,Windowsインスタンスのドメインジョインができる

IAM Identity Center

AWSが提供するシングルサインオンサービス

IDフェデレーション

https://kn.itmedia.co.jp/kn/articles/1607/25/news142.html

IdP

サービスで利用するユーザーを一元管理するところ
ユーザーを認証する場所のこと

SP

ログインするアプリケーションのこと
あらかじめSPはIdPと信頼関係の設定をすることでIDフェデレーションの仕組みを利用できる
(信頼する設定を「アサーション」という)

SSO(シングルサインオン)

例)Googleアカウントでログイン済みで、SPがGoogleをIdPとして信頼する設定をして、Googleアカウントの認証情報を使ってSPにログインすることができる。このような一度IdPでログインしていれば他のSPを使えるような仕組み

IAM Identity Center基本概念

https://product.st.inc/entry/2022/12/23/102300

IAM Identity Centerを有効化するとポータルが生成され、そこからパスワードなどを入力すると上記のような画面に遷移する。
上記の画面では、そのユーザーが持っているIAMロール、AWSアカウント、CLI用の一時的な認証情報などを各ユーザーごとに一元管理できる
(MFAの設定が可能)

外部IdPと連携
ユーザー管理の時にSAML2.0認証を使った外部IdPと連携できる
例)AzureAD, Okta

Organzitionsで他アカウント連携して他アカウトにログインできるような設定ができる

KMS

暗号化キーの作成、管理を行うサービス

3種類のキー

キーの種類 概要
カスタマーマネージドキー(CMK) 利用者が管理し利用者がアプリで暗号化/複合化する
AWSマネージドキー AWSが管理しAWSが暗号化/複合化する
AWS所有のキー AWSが裏側で管理しているキー

カスタマーマネージドキー(CMK)+カスタマーデータキー(CDK) 暗号化

https://qiita.com/kuromame1020611/items/464f1cdfb7f14fb8c4f3

  • CMKは利用者が管理し、利用するキーのこと
  • アプリケーションがKMSに対してデータキーの作成依頼(Generate DataKey)を出します
  • CMKからCDK(暗号化されていない)が作成されます。
  • CMKからCDK(暗号化された)が作成されます。
  • 2つのキー(暗号化された/されていない)を作成されます
  • CDK(暗号化されていない)方を使って、平文を暗号化します。
  • アプリケーション側で平文の削除、CDKの削除を行います。

カスタマーマネージドキー(CMK)+カスタマーデータキー(CDK) 復号化

  • アプリケーションがKMSに対してデータの復号依頼(Decript)を出します
  • CMKの情報をもとにCDK(暗号化された)復号化する

⇨ このような2つ以上の暗号化キーを利用する手法を「エンベロープ暗号化」

メタデータ
・作成日
・説明
・キーステータス
・マテリアルの参照先(暗号化アルゴリズムで仕様される文字列)
⇨ デフォルトではKMSが自動作成。ユーザーがインポートして利用することも可能(BYOK)

キーID
AWS内で識別するため(名前のようなもの)

自動ローテーション
中身のマテリアルが変わる(1年毎)

手動ローテーションすることもできる
ただ、全く新しいKMSを作成しなければならなくなる
すると、アプリケーション側でも変更を加えないといけないのでエイリアスを利用すると一意の名前を使って中身だけを変えることができる

キーポリシー
KMSへのアクセスを制御する。誰が使っていいのかを記述する。

AWSマネージドキー

KMS対象のAWSサービスによって生成/管理/使用される(無料)
aws/service-name形式で表示される

  • ユーザーの管理責任がない代わりにカスタマイズは不可
  • ローテートやキーポリシーの変更も不可

Cognito

ログインするための認証・認可をAWSが提供するサービス
不特定多数の一般ユーザー向けのサービス

Cognitoコンポーネント

ユーザープール

ユーザーの認証・管理する場所

https://qiita.com/zumax/items/6937b3ecb501b6ca50bb

AppからAWSへのアクセスをしたい。
だけれど不特定多数に向けたサービスのユーザー管理をしっかりとしないいけない
そこでCognito ユーザープールを利用する

マネージド方
Cognitoが提供するユーザーディレクトリを作成して独自でユーザーが管理する方法

外部のIdPを利用する場合
Cognitoは外部IdPと連携することが可能
Google,Facebook,Amazonなどと連携可能

IDプール

AWSサービスに対してのサービス
IAMロールを利用して一時的にクライアントにIAM権限の付与することができる

https://dev.classmethod.jp/articles/cognito-unauth-sample/

外部IDプロバイダーに認証を要求し、発行されたトークンをIDプールに渡してSTS(一時的なクレデシャンを発行)をクライアントは受け取りAWSサービスへとアクセスできる
(IAM Roleを渡している。未認証/認証ユーザー用のRoleを使い分けをすることができる)

ユーザープールとIDプールを連携

クライアント ⇨ ユーザープール(トークン取得) ⇨ IDプール(AWS認証情報取得) ⇨ AWSアクセス可能

https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/amazon-cognito-integrating-user-pools-with-identity-pools.html

AWS WAF

WEBアプリケーション(7層)に対するファイアーウォール
SQLインジェクション,DDos攻撃などを防げる

使用例)
CloudFront + AWS WAFのような構成で
CloudFront前の通信をブロックすることができる

https://dev.classmethod.jp/articles/aws-hands-on-for-beginners-cf-waf/

AWS WAFコンポーネント

WebACL

WAFのルールの集合体
ルールをまとめて対象のAWSサービスに適応する

マネージドルールグループ

AWSマネージドルール
⇨ AWSが提供してくれている一般的な攻撃を対応したルールを提供してくれる
新しい問題は自動更新

Market place
⇨ 各セキュリティベンダーが提供しているルール。専門的なルールを提供してくれている。
(別途利用料が発生する)

独自のルール

どう対処するのか定義するのか

ステートメント
⇨ リクエストを検査する方法を選択、設定をする
例)地理的一致、IPアドレス一致、正規表現パターンセット一致、SQLインジェクション攻撃

アクション
⇨ どのような実行するのかAllow Block、Conut(検知のみ)、CARTCHA(PCと人間を判別するもの)

ルールグループ
複数のステートメントとアクションをひとまとめにしたルールグループ
(ステートメント+アクション=ルール)

レートベースルール
どの程度リクエストあるかをカウントしたり制限値を判断する
例)5分間で同一のリクエストが100,000あったらブロックなど
(レートベースではなく、レギュラールールは上記で紹介したもの)

キャパシティ(Web ACL)

WAFのルールごとにWCUという数字が設けられている。
このキャパシティが1WebACLあたり1500内にすることという制約がある
※ Web ACL rule capacity Units

Shield

AWSの環境DDos攻撃から守るサービス
フルマネージドで防いでくれる

種類 内容 レイヤー
Standard 無料かつ自動で有効化。特別な設定は不要 L3 / 4 レイヤーを保護
Advanced 有料。大規模なDDoS攻撃に対応している。24/365のAWSサポートチームを利用できる L3 / 4 / 7レイヤーを保護

GuardDuty

AWS環境でセキュリティ悪影響を及ぼす誤操作、環境設定を検知してくれるサービス
脅威の発見はAWSが機械学習を用いて発見してくれる

確認/検知するもの

サービス 監視対象
VPC Flow Logs IPトラフィック監視
Route53 DNSクエリ監視
CloudTrail AWSのAPIの操作を監視

GuardDutyを有効化すればスタートすることができるため導入までの時間が短くて済む
GuardDutyは他のサービスと統合もできる(SecurityHubなど)

Discussion