IAM、セキュリティ
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フェデレーション
IdP
サービスで利用するユーザーを一元管理するところ
ユーザーを認証する場所のこと
SP
ログインするアプリケーションのこと
あらかじめSPはIdPと信頼関係の設定をすることでIDフェデレーションの仕組みを利用できる
（信頼する設定を「アサーション」という）
SSO(シングルサインオン)
例）Googleアカウントでログイン済みで、SPがGoogleをIdPとして信頼する設定をして、Googleアカウントの認証情報を使ってSPにログインすることができる。このような一度IdPでログインしていれば他のSPを使えるような仕組み
IAM Identity Center基本概念
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コンポーネント
ユーザープール
ユーザーの認証・管理する場所
AppからAWSへのアクセスをしたい。
だけれど不特定多数に向けたサービスのユーザー管理をしっかりとしないいけない
そこでCognito ユーザープールを利用する
マネージド方
Cognitoが提供するユーザーディレクトリを作成して独自でユーザーが管理する方法
外部のIdPを利用する場合
Cognitoは外部IdPと連携することが可能
Google,Facebook,Amazonなどと連携可能
IDプール
AWSサービスに対してのサービス
IAMロールを利用して一時的にクライアントにIAM権限の付与することができる
外部IDプロバイダーに認証を要求し、発行されたトークンをIDプールに渡してSTS(一時的なクレデシャンを発行)をクライアントは受け取りAWSサービスへとアクセスできる
（IAM Roleを渡している。未認証/認証ユーザー用のRoleを使い分けをすることができる）
ユーザープールとIDプールを連携
クライアント ⇨ ユーザープール（トークン取得） ⇨ IDプール（AWS認証情報取得） ⇨ AWSアクセス可能
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