SEワンタンの独学備忘録

IT関連の独学した内容や資格試験に対する取り組みの備忘録

【AWS】ソリューションアーキテクトアソシエイト対策⑥(IAM、セキュリティ機能)

この辺は勉強しててもあまり面白さがあるところではなくてちょっとつらい。

AWS Identity and Access Management (IAM)

ユーザアカウントについて

前提として、ユーザアカウントにはAWSアカウントが存在する。
AWSアカウントは契約単位、請求の単位になる。

AWSアカウントは互いに独立しており、特別に設定を行わない限りは互いのリソースにアクセスすることはできない。

実際にAWSリソースを日常的に使用するのは、IAMユーザでの使用が推奨されている。
無料枠で使用する場合でも同様。実際に私が実機学習を行った際にもそうしました。

IAMの概要

■関連記事

www.wantanblog.com

大層なことはやっていませんが、上記でIAMユーザの作成を行っています。

正式名称は「AWS Identity and Access Management」という。
IAMにはIAMユーザとIAMグループの大きく2種が存在する。

・IAMユーザ
実際にAWSリソースの操作を行うユーザ単位に作成する。
AWSアカウントにつき、5000ユーザ作成可能であり、作成した段階では権限を持たないのでIAMポリシーを付与することによって操作権限を与える。


・IAMグループ
IAMユーザの集合単位。AWSアカウントにつき100グループの作成が可能。
IAMグループによる組織のような階層構造を構築することはできない(横並びの関係となる)。


■ユーザアカウントの認証設定

・ユーザID/パスワード
マネジメントコンソールにログインする最も基本的な認証方法。

・MFA(多要素認証)
マネジメントコンソールにログインするためにパスワード以外に設定する。
ワンタイムパスワードとか。

・アクセスキーID/シークレットアクセスキー
API利用をする際に必要になる。

・X.509証明書
公開鍵証基盤(PKI)の規格。
APIを利用する際の証明として使用される。


IAMポリシー

IAMユーザにはIAMポリシーを設定することによりAWSリソースへの操作権限を与える。
ポリシーにはポリシーの付与権限を与える管理ポリシーと直接の操作権限を与えるインラインポリシーが存在する。

また、管理者が定義する権限を細かく設定できるカスタマー管理ポリシーが存在する。

■カスタマー管理ポリシーの記述方法

{
"Version": "2012-10-17",
"Id": "S3-Account-Permissions",
"Statement": [{
"Sid": "1",
"Effect": "Allow",
"Principal": {"AWS": ["arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:root"]},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::mybucket",
"arn:aws:s3:::mybucket/*"
]
}]
}

引用元:ポリシーとアクセス許可 - AWS Identity and Access Management

Effectでは許可と拒否を設定する。
Actionにはインスタンスの作成などの操作権限を記述する。ワイルドカード「*」の場合は全権限を意味する。
Resourceには、対象のリソースを記述する。
他にも適用の条件を記述するConditionなどがある。


■明示的Deny(拒否)

IAMユーザが複数のグループに所属する場合などに、一つでもDenyが存在した場合はAllowがあってもDenyが優先され、操作が拒否される。
セキュリティ的には一般的な考え方な気がするので、ITリテラシーが高ければそこまで意識する必要はないかもしれない。


■リソースベースポリシー

ユーザやグループではなく、リソースベースにインライン形式でのポリシーを設定することが可能である。
※個人利用ではあまり意識することがなかった。

ユースケース的には、S3バケットの公開範囲を制限するために、特定のIPアドレスからのみ操作を許可する場合など。

IAMロール

普通に考えると権限のまとまりをユーザに付与するものな気がするけど、それは誤りで、
AWSリソースの操作権限をAWSサービス(EC2とか)に付与するもの。
※AD連携した場合にはユーザに付与したような形になるのでこの解釈は微妙かも??とりあえずIAMユーザにつけるのはポリシー。



IAMロールの活用によってAWSサービスから他のサービスの利用を許可することができる。
※確かにLamdaでロールを設定していたのを思い出してきた。


■一時的セキュリティ認証情報(STS)

IAMロールの場合、認証にはSTSが生成する一時認証情報を利用する。
通常のアクセスキーを使用することもできるが、ローテーションなど、管理の手間が増える。


■Switch Role

IAMユーザがマネジメントコンソールから他のAWSアカウントへアクセスするための権限付与。

アカウントAのIMAユーザがアカウントBにアクセスしたい場合は、アカウントB側でSwitch Roleを作成し、付与する。


IDフェデレーション

IAMユーザを別途作成せずに外部の管理ディレクトリやIDプロバイダーなどを使用してAWSリソースにアクセスできるようにする仕組み。
IDフェデレーションでは認証情報はSTSから発行された認証情報を使用してアクセスする。
権限自体はIAMロールによって設定する。

この辺は弱い。。単に覚えるのは結構辛そう。。
けど試験的にはまぁまぁ重要になってくるっぽいですね。

■SAML2.0

SSOとかででてくるあのSAML。
IDプロバイダー側がSAML2.0に対応している場合、IAM SAML2.0 IDプロバイダーによるID連携が可能となる。

■OpenID Connect

IDプロバイダー側がOpenID Connectに対応している場合、IAM OpenID Connect IDプロバイダーによるID連携が可能となる。
Twitterアカウントとかの利用が該当する。ウェブIDフェデレーション。

OpenID Connect自体は認証プロトコルという認識でいいっぽい?

■LDAP

SAML 2.0 との互換性がない場合、カスタム ID ブローカーアプリケーションを作成して同じような機能を実行できます。ブローカーアプリケーションはユーザーを認証し、そのユーザー用に一時的な認証情報を AWS に要求して、それをユーザーに提供し AWS リソースにアクセスできるようにします。
引用元:外部で認証されたユーザー(ID フェデレーション)へのアクセスの許可 - AWS Identity and Access Management

LDAPに限らず、SAML 2.0に対応していない場合は、カスタム ID ブローカーというものを作成しないといけないらしい。
そうするとLDAP認証を通せばAWSサービスの利用ができると。

■Active Directory

Active Directory(AD)はADFSを適用することによってSAML 2.0に対応するが、そうできない場合、AWS Directory Servise ADConnectorを使用する。
ADにリダイレクトすることによって、認証を行う。

■モバイル認証

モバイルアプリケーションがソーシャルIDを利用して認証を行う場合、Amazon Cognitoが使用される。
アプリ側がSAML2.0に対応していない場合はLDAP同様カスタム ID ブローカーの作成が必要になる。


セキュリティ機能全般

一部、他のサービスと被る部分もありますが、セキュリティでまとめます。IAMででてきた内容も一部ある。

責任共有モデル

AWSでは、利用者とAWSがセキュリティの責任を分担し相互にもつ、責任共有モデルがとられている。

・利用者側
データ暗号化、OS、ネットワーク、ファイアウォール、アプリケーションセキュリティ、

・AWS側
データセンター、物理セキュリティ、物理資源


マネージドサービスを利用する場合は、バッチ管理も含めてAWS側で責任を持つ

AWS Directory Service

AWSのマネージド型ディレクトリサービス。大きく3種ある。

■Simple AD

ディレクトリサービスとして、ユーザアカウント、グループメンバーシップ、Windowsインスタンスのドメイン参加などが実現できる。
基本的には同一VPC内で使用する。


■AWS Managed Microsoft AD

Windows Server上にADを構築したマネージドサービス。
オンプレのADと信頼関係を構築できる。

提供機能は以下の通り。

・ユーザーとグループを管理する
・アプリケーションとサービスにシングルサインオンを提供する
・グループポリシーを作成し適用する
・Amazon EC2 Linux および Windows インスタンスに安全に接続する
・クラウドベースの Linux および Microsoft Windows ワークロードのデプロイメントと管理を簡素化する
・AWS Managed Microsoft AD を使用すると、既存の RADIUS ベースの MFA インフラストラクチャと統合し、多要素認証を有効にして、ユーザーが AWS アプリケーションにアクセスするときに追加のセキュリティレイヤーを提供できます
引用元:
AWS Managed Microsoft AD - AWS Directory Service


■AD Connecter

AWSアプリケーションの認証を行う際にオンプレのADにリダイレクトする。

具体的にはユーザがマネジメントコンソールを使用する際に、AD ConnecterからオンプレADにリダイレクトし認証を行う。
認証結果をAD Connecterを返却しマネジメントコンソールの使用が開始できる。

AWS Single Sign-on

SAML2.0に対応するシングルサインオンを実現するマネージドサービス。

ユーザ認証はAWS側のリソースで行う場合は、AWS SSOのローカルディレクトリかADを使用する。
オンプレを利用する場合には、前述のAWS Managed Microsoft ADにより信頼関係を構築するか、AD Connecterによるリダイレクトによって認証を行う。

SSOを構築した場合には、SAML IDPとして機能する。

Amazon Guard​Duty

もうこの辺はしばらく全然きいたことも調べたこともない。つらい。


AWSアカウントとワークロードを保護するために操作や動作をモニタリングする脅威検出サービス。
IPアドレス、機械学習、異常検出などにより異常を検知する。

AWS CloudTrail、Amazon VPC フローログ、DNS ログなど、複数の AWS データソースにわたる数千億のイベントを分析します。AWS マネジメントコンソールを数回クリックするだけで、ソフトウェアやハードウェアを使用することなく、GuardDuty を有効にし、デプロイやメンテナンスを行うことができます。AWS CloudWatch イベントと統合することで、GuardDuty アラートは実用的となり、複数のアカウントにわたっての集計や、既存のイベント管理およびワークフローシステムへのプッシュを簡単にします。
引用元:Amazon GuardDuty(マネージド型脅威検出サービス)| AWS

正直まとめるのが難しい。セキュリティ面での異常を検知して通知はCloudWatchにまかせ、アクション実行はLamdaに任せるみたいな感じか。

Amazon Inspector

自動化されたセキュリティの評価サービス
EC2インスタンスのアプリケーションとネットワークの状態をテストする。

評価を行うルールパッケージには共通脆弱性識別子(CVE)などが用いられる。

AWS Shield

AWS Shield はマネージド型の分散サービス妨害 (DDoS) に対する保護サービスで、AWS で実行しているアプリケーションを保護します。AWS Shield ではアプリケーションのダウンタイムとレイテンシーを最小限に抑える常時稼働の検出と自動インライン緩和策を提供しているため、DDoS 保護のメリットを受けるために AWS サポートに依頼する必要はありません。AWS Shield にはスタンダードとアドバンストの 2 つの階層があります
引用元:AWS Shield(マネージド型の DDoS 保護)| AWS

DDoS攻撃の保護を行うマネージドサービス。アドバンストでは攻撃によるコスト高騰の保護が含まれる。

AWS ウェブアプリケーションファイアウォール (WAF)

AWS WAF は、アプリケーションの可用性に対する影響、セキュリティの侵害、過剰なリソース消費を生じる可能性がある一般的なウェブエクスプロイトからウェブアプリケーションを保護するために役立つウェブアプリケーションファイアウォールです。AWS WAF では、カスタマイズ可能なウェブセキュリティルールを定義することによって、ウェブアプリケーションに対するどのトラフィックを許可またはブロックするかを制御できます。AWS WAF は、SQL インジェクションまたはクロスサイトスクリプティングなどの一般的な攻撃パターンをブロックするカスタムルール、および特定のアプリケーションのために設計されたルールを作成するために使用できます
引用元:AWS WAF(ウェブアプリケーションファイアウォール)| AWS

SQLインジェクションやXSSとかを防ぐ、機能的には通常のWAFと同じような認識でよさそう。
Cloud FrontALBに統合され、不正なアクセスなどはその段階で弾けるとか。

AWS Key Management Service(KMS)

AWS Key Management Service (KMS) を使用することで、暗号化キーを簡単に作成して管理し、幅広い AWS のサービスやアプリケーションでの使用を制御できるようになります。AWS KMS はセキュアで弾力性の高いサービスで、キーを保護するために FIPS 140-2 の検証済みまたは検証段階のハードウェアセキュリティモジュールを使用します。AWS KMS は AWS CloudTrail と統合されており、すべてのキーの使用ログを表示できるため、規制およびコンプライアンスの要求に応えるために役立ちます。

データの暗号化に使用するキーをセキュアに保護する。

AWS CloudHSM

AWS CloudHSM は、クラウドベースのハードウェアセキュリティモジュール (HSM) です。これにより、AWS クラウドで暗号化キーを簡単に生成して使用できるようになります。CloudHSM で、FIPS 140-2 のレベル 3 認証済みの HSM を使用して、暗号化キーを管理できます。CloudHSM によって、PKCS#11、Java Cryptography Extensions (JCE)、Microsoft CryptoNG (CNG) ライブラリといった業界標準の API を使用して、アプリケーションを柔軟に統合できます。
引用元:AWS CloudHSM(法令遵守のためのハードウェアベースキーストレージ)| AWS

HSMは暗号化に用いる鍵の保護を行う。
うーんどこまで重要になるのか。感覚的にわかりにくい部分。



余談ですが、量子コンピューティングサービスのAmazon Braketが発表されていましたね。
事前知識がない個人が使用するにはまだ敷居が高い気もしますが、ぼやぼやしてるとサービスが増えたり変わったりしちゃうなぁ。