📖

【未経験者向け】ポリシー・認証サービスを抑えよう

2023/06/30に公開

AWS

経緯

転職活動をするにあたり、複数企業方のTLからわずかながらお話をお伺いすることがありました。実務未経験者からしては気になる点、それは抑えていてほしいAWSサービスは何であるか。DBや自動化に関しての回答もありましたが、ダントツに多いのはセキュリティや認証部でした。
情報社会から出遅れている本国としては、既知の認識だったのでしょうか・・・
それ故に、これまでに学習してきた認証部、ポリシー部。いわば運用するサービスやシステムを保護するには、どのようなサービスが用意されており「何が」「どのような時に使えるか」、ここをポイントとして以下に記載しました。

①IAM 関連について

IDとAWS のサービスおよびリソースへのアクセスを安全に管理する。企業が利用するシステムごとに設定された複数のIDを統合管理し、同時にアクセス権限の適切な管理を行う。

●IAMユーザー
ルートアカウントに加えて、下記二つがあります。

管理者権限：ルートアカウントと同等の権限はない
パワーユーザー：IAMの操権限なし

※ルートアカウント(IAMではない)＞管理者権限(IAMユーザー)＞パワーユーザー(IAMユーザー)

【１】ルートユーザーのみの実施権限

AWSルートアカウントのメールアドレスやパスワードの変更
IAMユーザーの課⾦情報へのアクセスに関するactivate/deactivate
他のAWSアカウントへのRoute53のドメイン登録の移⾏
AWSサービス（サポート等）のキャンセル
AWSアカウントの停⽌
コンソリデイテッドビリングの設定
脆弱性診断フォームの提出
逆引きDNS申請

【２】認証方式

アクセスキーID/シークレットアクセスキー
X509 Certificate
マネジメントコンソール MFA:Multi-Factor Authentication(多要素認証)
⇒ユーザーのスマートフォンからのコード,秘密の質問の答え,指紋,顔認識などを要求

●IAMアクセスキー
S3やEC2といったAWSの各サービスに対してプログラムにおけるアクセスを認証するために作成される認証キー。

【IAMポリシー】

AWSサービスやAWSリソース(リソース間の連携)に対する操作権限をIAMポリシーとして定義したのち、IAMポリシーをIAMユーザーやIAMグループにアタッチする。

●インラインポリシー
特定のIAMユーザやIAMロール専用に作成されるポリシー。（使いまわしができない）
「ポリシー」単体では存在できず、プリンシパルエンティティと1対1の関係にある。
1つのIAMユーザなど、1対1でのアタッチしかできない。

●カスタマー管理ポリシー
ユーザー（お客様）自身が管理できる管理ポリシー。

IAMロールはコード上で実行してWEBアプリケーション同士を連携する際には利用できない
JSON/YAMLなどのコードでインフラ構築方式がポリシーとして定義されている

★JSON形式で[Action(どのサービスの)],[Resource(どういう機能や範囲を)],[許可/拒否]を記載

●AWS管理ポリシー(マネージド)
予めAWSによって用意されている管理ポリシー。「ポリシー」単体として存在できて、複数のプリンシパルエンティティにアタッチして利用可能。

一元化されている：ポリシーを変更するとアタッチされている全てのプリンシパルエンティティが変更適用
バージョニング、ロールバック可能。アクセス許可管理の委任が可能

【１】ポリシーの検証・テスト

以下の2つを使用してポリシーをテストすることが可能。

●IAMPolicy Simulator
IAMのポリシー設定をテストできる。アイデンティティベースのポリシー、IAMアクセス許可の境界、組織のサービスコントロールポリシー、リソースベースのポリシーをテストおよびトラブルシューティングできる。

●DryRun（プール値）
実際に要求を行うことなく、アクションに必要な権限があるかどうかを確認し、エラー応答を提供する。必要な権限がある場合、エラー応答はDryRunOperationとなる。

【２】サービスコントロールポリシー (SCP)

組織のすべてのアカウントで使用可能な最大アクセス許可を一元的に制御できる組織ポリシーの一種。
アカウントが組織のアクセスコントロールガイドラインに従っていることを確認するのに役立つ。
AWSアカウント,組織単位(OU)内のアカウントのグループに対してAWSサービスへの権限境界を設定できる。
SCP自体は権限を与えるものではなく、「ここまでは許可できる」という境界を設定。
SCPを使用するにはすべての機能を使用する許可が必要。

★AWSアカウントにデフォルトで「FullAWSAccess」が付与されている場合、どのように拒否形式（ブラックリスト形式）のSCPが機能に関するか。
デフォルトでは「FullAWSAccess」が付与されている場合、全リソースに対する全操作が明示的に許可されている状態。そこに、ブラックリスト形式で特定の操作を拒否すると、対象リソースの操作が拒否されるものの、その他のリソースについては「FullAWSAccess」が維持された状態となる。

【３】アクセス許可の境界

IAMの高度な機能で、管理ポリシーを使ってIAMエンティティ（ユーザーやロール）に付与できるアクセス許可の最大限度を設定できる。

管理ポリシーを使用してアイデンティティベースのポリシーがIAMエンティティに付与できるアクセス許可の上限を設定する高度な機能。
エンティティはアイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクションのみを実行できる。
IAMエンティティ（ユーザーまたはロール）の境界を設定するには、AWS管理ポリシーまたはカスタマー管理ポリシーを使用する。

【４】IAMデータベース認証

IAM ユーザーまたはロール認証情報と認証トークンを使用して RDS DB インスタンスまたはクラスターに接続。

認証トークンの有効期間は 15 分。
IAM データベース認証トークンは、AWS アクセスキーを使用して生成。
データベースユーザーのパスワードなど資格情報を保存する必要はない。
IAM データベース認証は Secure Socket Layer (SSL) 接続が必要で、DB インスタンスとの間で送受信されるすべてのデータは暗号化される。
アプリケーションが Amazon Elastic Compute Cloud (Amazon EC2) で実行されている場合、EC2 インスタンスプロファイル認証情報を使用してデータベースにアクセスできる。
※RDSによって立ち上げたMySQLなどにアクセスする際(通常はユーザー名とパスワードを利用してアクセス） ⇒IAMデータベース認証を有効化：IAMロールを利用したアクセスが可能。

【外部ポリシー】

●ID プロバイダー (IdP)
既にユーザーIDをAWSの外で管理している場合、AWS アカウントに IAM ユーザーを作成する代わりに、IAM ID プロバイダーを利用できる。
AWS の外部のユーザー ID を管理して、これらの外部ユーザー ID にアカウント内の AWS リソースに対するアクセス許可を与えることができる。
⇒外部ユーザーは、よく知られた IdP (例: Login with Amazon、Facebook、Google) を使用してサインインする。

会社に既に企業ユーザーディレクトリなどの独自の ID システムがある場合に便利。
IAM ID プロバイダーエンティティを作成して、AWS アカウントと IdP の間に信頼関係を確立する。
AWS リソースへのアクセスが必要なモバイルアプリやウェブアプリケーションを作成する場合にも便利。

★IAMは、OpenID Connect (OIDC) または SAML 2.0 (Security Assertion Markup Language 2.0) と互換性のある IdP をサポートする。

●IAMロール
一時的にAWSリソース（サービス）へアクセスする権限を付与する。
【例】EC2インスタンス上で稼働するアプリケーションに一時的にAWSのリソースへアクセスする権限を与えたい
　(EC2インスタンス作成時にロールを付与することで可能)

※作成時のみ可能な操作、既存には付与できない

AWS Organization (組織アカウント)

複数アカウントに適用するポリシーを管理できる。グループを作成し、そのグループに対してポリシーを適応することでサービスへの使用を制限できる。
サービスのアクセス制御OU(組織単位) や SCP(サービスコントロールポリシー) を使用ことで複数のアカウントで使用できるサービスを管理することが出来る。
(※管理アカウントは組織のルートアカウントであり、OUに含めることはできない)
アカウントの作成・管理を行うことが出来る。 APIを使用することで新規アカウント発行・グループに追加を行い、すぐに使用することが出来る。
マスターアカウントを使用して、組織で使用したAWSの費用を統合して支払うことが出来る。
Organization（SCP）AWS Organizationsを使用すれば、APIから新規アカウントを作成して管理できる
(※従来はAWSのアカウントを作る際、カード番号の入力や電話認証など、煩雑な対応が必要だった)

【一括請求機能】

複数の AWS アカウントまたは複数の Amazon Web Services India Private Limited (AWS India) アカウントの支払いを統合できる。
Organizations のすべての組織には管理アカウントがあり、すべてのメンバーアカウントの請求を支払う。

【アクセス権限セット】

ユーザーおよびグループが持つアクセスのレベルを定義する。
権限セットは IAM Identity Center に保存され、1 つ以上にプロビジョニングできる。AWS アカウント複数のアクセス権限セットを 1 人のユーザーに割り当てることができる。

【利点】

1つの請求書：複数のアカウントに対して 1 つの請求書を受け取るだけで済む。
簡単な追跡：複数のアカウントでの料金を追跡し、コストと使用状況の統合データをダウンロードできる。
使用状況の結合：組織内のすべてのアカウントの使用量を結合し、料金のボリューム割引、リザーブドインスタンスの割引、および Savings Plans を共有できる。その結果、会社、部門、またはプロジェクトでの料金が個々のスタンドアロンアカウントと比較して低くなる。
追加料金なし：一括請求は追加コストなしで提供される。

②補足知識

【１】認証情報レポート

アカウントのすべてのユーザーと、ユーザーの各種認証情報 (パスワード、アクセスキー、MFA デバイスなど) のステータスが示された認証情報レポートを生成し、ダウンロードできる。
AWS Management Console、AWS SDK、コマンドラインツール、または IAM API から取得できる。

認証情報レポートを使用して、監査やコンプライアンスの作業支援をすることができる。
このレポートを使用して、パスワードやアクセスキーのローテーションなど、認証情報ライフサイクルの要件の結果を監査できる。
外部の監査人にこのレポートを提供することも、監査人が直接このレポートをダウンロードできるようにアクセス権限を付与することもできる。
4 時間ごとに 1 回生成できます。レポートをリクエストすると、IAM はまず AWS アカウントについて過去 4 時間以内にレポートが生成されたかどうかを確認する。

【２】クロスアカウントアクセス

複数のAWSアカウント間のリソースを一つのIAMユーザーで操作したい時に利用する。

③認証・認可機能

【認証・認可の違い】

認証：その人が誰であるかを判別すること。
認可：その人が何を許可されているかを判別すること。
➡AWS SSOは「会社内 (組織内) のユーザー認証・認可で用いる」一方、Cognitoは「不特定多数（組織外）の一般ユーザーの認証・認可」を行うことができるサービス。

【１】【組織内向け】AWS SSO (Single Sign ON)

1組のID・パスワードによる認証を1度行うだけで複数のサービスにログインできるようにする仕組み。
➡システムを利用する際に、ユーザー側が1組のID・パスワードを覚えておけばいいため、ユーザーの利便性が向上するだけでなく、セキュリティもより強固になる。
➡AWS SSOは、複数のAWSアカウントへのアクセスを行う際に、Single-Sign-Onを提供→本番環境・開発環境にアクセスするときにも有効。

【２】【不特定多数向け】Cognito

AWSなどに構築した、Web・モバイルアプリケーションに認証・認可機能を提供するサービス。
利用するユーザーが自分でIDの登録が可能であるほか、FacebookやGoogle、Appleなどのアカウントと連携できる機能を持っている。

ウェブアプリケーションおよびモバイルアプリに素早く簡単にユーザーのサインアップ/サインイン、アクセスコントロールの機能を追加できるサービス。
「認証」、「許可」、「ユーザ管理」をサポートしており、ユーザー名とパスワードを使用して直接サインインする方法もある。
一意IDを作成して認証されていないユーザーを許可し、AWSリソースへの制御されたアクセスを許可する。
開発者が更新された同期されたデータとしてイベントを受信できるようにKinesisストリームを設定できる

【認証：ユーザープール】（アクセスできるトークン発行窓口）

ユーザー「認証」機能を提供。

ユーザープールへのサインイン後に入手できるIDトークン(JSON Web トークン (JWT) を発行し、IDプールへつなげる、サインアップおよびサインインサービス。
Cognito自体にユーザーIDを登録する機能と、外部のIDプロバイダー（GoogleやFacebookなど）と連携する機能が存在する。

●ユーザーディレクトリ
アプリ内部の領域でありIDやパスワードの認証情報を保存し、その情報を利用してアプリの「認証」を行う。

その人が誰なのか（アイデンティティの検証）、を確認する。
ユーザープールにユーザーが作成されると、Cognitoが一意のIDを割り振る。
ユーザーは Google、Facebook、Amazon、Apple などの「外部IDプロバイダー（「IDP」と呼ばれる）」、および SAML ベースの ID プロバイダー経由でユーザープールに認証、サインインすることもできる。
ユーザーディレクトリとユーザープロファイルの管理。

【認可：IDプール】(トークンに対して一時的な権限(Credetials)を発行

外部のIDプロバイダーによって認証されたIDに対して、AWSへのアクセス権限を払い出す、認可の機能を持っている。
具体的には、認証されたユーザーに、AWS上のアプリケーションに対するアクセス権を持つ「Credentials」を発行することができる。
また、Webアプリケーションなどを想定し、認証されていないゲストユーザーにも、一部のアクセス権を付与する、といった機能を持っている。
➡Credentials の実体は、IDプールに事前に設定された IAM ロールを、AWS STS がユーザーのリクエスト毎に発行したIAMロールと同等の権限を持った一時的な認証情報を指す。
➡事前にIAMロールとSTSの紐づけが必要になる

※Amazon Cognito ID プールは、以下の ID プロバイダーをサポートする

パブリックプロバイダー: Login with Amazon (ID プール)、Facebook (ID プール)、Google (ID プール)、「Apple でサインイン」 (ID プール)。
Cognito ユーザープール
Open ID Connect プロバイダー (ID プール)
SAML ID プロバイダー (ID プール)
デベロッパーが認証したアイデンティティ (ID プール)

【１】プッシュ同期機能
自動的にIDとデバイス間の関連付けを追跡する。IDデータが変更された時、特定のIDのすべてのインスタンスにプッシュ通知をする。
また、特定のIDの同期ストアデータが変更されるたびに、そのIDに関連付けられているすべてのデバイスが通知を受け取る。

Cognito ストリーム
すべてのSyncデータをKinesisに移動して、分析するためにDWHにストリーミング処理ができる
Cognito Sync
認証したデータを共有することができるようになる。
Cognitoを使ってログインしたユーザーデータやアプリケーションデータを複数のデバイス間で共有することができる機能を提供。
Cognito イベント
Cognitoにおける重要なイベントに応じてLambda関数を実行できる。
Cognito コールバック
データセットの同期に関するアクティビティのコールバックイベントを処理する

【３】STS(Security Token Service)

一時的なセキュリティキーを作成することで、信頼するユーザーへ操作・管理を許可する(アクセスキー)AWS リソースへのアクセスを許可する。

「有効期限」を設定して一時的な許可が可能な点と、リクエストに応じてその都度動的に作成されるため、ユーザーに紐づいて保存されない。
AWS IDを発行せずに済むため、一時的なアクセスが必要なユーザーに対してとても有効な手段。
ユーザーに対して AWS ID を定義せずに AWS リソースへのアクセスを許可できる
　➡（IDフェデレーション）
認証情報として、「アクセスキー」、「シークレットキー」、「セッショントークン」の3つ（セキュリティ認証情報セット）が発行される。

●Decode Authorization Message：エンコードされたエラーメッセージのデコードに役立つ。

【フェデレーション（ID連携ともいう）】

一度の認証で複数のシステムを使ったり、複数のサービス（クラウドなど）を受けられるようにするための仕組み。

【１】ウェブIDフェデレーション

AmazonやSNS、Googleのユーザー(IdP：IDプロバイダー)がトークンを発行することでサインインしてもらい、その時に外部サービスのユーザー情報とIAMロールを紐づけて一時的にアクセス権限を付与する。
会社に既に企業ユーザーディレクトリなどの独自の ID システムがある場合に便利。

●外部ID
IAMロールの信頼ポリシーでオプションの情報として使用することで、ロールを引き受けることが可能なユーザーを指定することができる。

【２】SAML 2.0 (Security Assertion Markup Language)

異なるインターネットドメインの通信を実現するための通信プロトコル。
クラウドサービスやアプリへのシングルサインオンを実現するための認証機能として使用されるこの機能はフェデレーティッドシングルサインオン (SSO) を有効にする。
組織内の全員に IAM ユーザーを作成しなくても、ユーザーは AWS マネジメントコンソールにログインしたり、AWS API オペレーションを呼び出したりできるようになる。

④その他認証サービス

AWS Resource Access Manager (RAM)(リソースの共有)

AWS のリソースを任意の AWS アカウントまたはAWS 組織内で簡単かつ安全に共有できるサービス。

AWS Transit Gateway、サブネット、AWS License Manager の設定、Amazon Route 53 リゾルバーのルールのリソースを RAM で共有できる。
複数組織では管理や請求の分離を行い、エラーの影響を制限するために複数のアカウントを使用。
複数のアカウントに重複するリソースを作成する必要がなくなり、所有するすべてのアカウントでこれらのリソースを管理するための運用オーバーヘッドが削減できる。

Secrets Manager（DBの認証にも有効）

データベースの認証情報や、パスワードなどの任意のシークレット情報をAPIコールで取得できるためのAWSサービスの一つ。各サーバからこのAPIを叩くことでシークレット情報を取得でき、認証やサーバセットアップに利用できる。
●シークレット
パスワード、ユーザーネームやパスワードなどの一連の認証情報、OAuth トークン、または、暗号化された形式
●メリット
アプリケーションにシークレット情報を保存する必要がなくなる。
＜参考リンク＞ https://docs.aws.amazon.com/ja_jp/secretsmanager/latest/userguide/intro.html"

ACM (AWS Certificate Manager)

AWS自身が認証局となる SSL証明書を集中管理する。
ACM はAWS サービスとユーザーの内部接続リソースで使用するパブリックまたはプライベートのSSL/TLS 証明書を作成・登録・管理することができる。

とても大雑把に説明するとAWS上でSSL/TLSを利用することが可能となるサービス。
SSL/TLS：インターネットで情報を送受信する際の仕組み（プロトコル）の一種で、サーバ〜PC間の通信を暗号化して安全を担保してくれる。
※通常SSL/TLSを利用するには、クライアントに説明して、CSR（Certificate Signing Request）ファイルと呼ばれる証明書の発行申請書を作成して、認証局にお金を支払って、証明書を発行してもらい、サーバへインストールするなどの手続きが必要になる。

【AWSサービスを利用してWEBサイトをSSL化する場合】

ELBにSSL証明書をインストールしEC2の手前にELBを設置

SSL証明書を集中管理するためのAWSサービス
SSL/TLS 証明書の購入、アップロード、更新という時間のかかるプロセスを手動で行う必要がなくなる
SHA-256のSSL/TLSサーバ証明書の作成・管理を行う
有効期限は13か月で自動更新される
無料

AWS VM Import

仮想化環境からに VM を Amazon マシンイメージ (AMI) として Amazon EC2 にインポートする機能。 AMI から EC2 インスタンスをいつでも起動できる。