# AWS勉強会 第4回~IAMって何者、VPCとは~ # IAMとAWSアカウント ## AWS アカウント AWSクラウドと契約すると、以下が作成 - アカウントID - ルートユーザ それぞれのAWSアカウントは課金(請求)/セキュリティ/ネットワークに関して独立 <br> この特徴を活かして * 本番環境と検証環境を各アカウントで分離でオペミス防止 * システムごとのコストを明確に分ける <br> ## AWS Organizations 複数のAWSアカウントをポリシーベースで一元管理するサービス<br> 統一的なポリシー設定、メンバーアカウントの一括請求、予算/セキュリティ/コンプライアンスの階層的なグループ化が可能<br> OU(組織単位)で管理され、OUに対して異なるポリシーを割り当て可能 ![](https://i.imgur.com/IEcW8l5.png) ## AWS ユーザアカウント * AWS IAM … AWS Identity and Access Managementの略 * AWSリソースへ安全にアクセスするための認証/認可サービス <br> ### AWSユーザアカウントの種別 | | ルートユーザー | IAM ユーザ | | -------- | -------- | -------- | | AWSサービス/リソースへの<br>アクセス権限 | すべての<br>権限を持つ | IAM管理者により許可された<br>範囲の権限を持つ | | ログインID | AWSアカウント登録時の<br>Eメールアドレス | IAM管理者により<br>作成されたユーザ名 | | 運用時の利用 | 日常の操作には<br>使用しないことを推奨 | 日常のAWS<br>管理作業に利用 | <br> ### IAMユーザとグループ | | IAMユーザー | IAMグループ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| | -------- | -------- | --------| | 目的 | AWS操作用のID | IAMユーザをまとめる | | 1つのAWSアカウント<br>当たりの上限 | 5000 | 100 | | 設定可能な情報 | ユーザ名、パス、<br>所属グループ、パーミッション | グループ名、パス、<br>パーミッション | | 特徴 | ユーザが作成されたときは<br>なにも権限を持たない |グループはほかのグループに<br>入れることはできない。<br> グループは認証情報は<br>持たない | <br> ### IAMで使用可能な認証情報 | IAMユーザ認証対象 | IAMユーザ認証情報と認証メソッド | | --------------- | ---------------| | AWSマネジメント<br>コンソール | ユーザID/パスワード<br>MFA(多要素認証) | | API操作,REST,<br>Query形式,AWS CLI操作 | アクセスID/<br>シークレットアクセスキー | | API操作,SOAPリクエスト | X.509証明書 | * セキュリティ上、IAMユーザのパスワードやアクセスキーID/シークレットアクセスキーの認証情報は定期的にローテーションすることが推奨<br>→認証情報の利用状況は、AWSマネジメントコンソールおよび認証情報レポートで確認可能 * プログラムコードに直接記入すると、プログラムを共有したときに漏洩するリスクがある。 <br> ### パスワードポリシー パスワードポリシーを指定することで、IAMユーザーが簡単なパスワードを設定できなくなる。 #### IAMパスワードポリシー設定可能な内容 | パスワードポリシー設定項目 | 設定可能内容 | |:----------------------|:----------------------------| | パスワードの<br>文字に対する項目 | 最小文字数、大文字の要求、<br>小文字の要求、数字の要求、 特殊文字の要求 | | パスワードの変更、<br>有効期限に関する項目 | ユーザー自身によるパスワード変更、<br>有効期限、再利用の制限、<br>有効期限切れになった場合の<br>IAM管理者によるリセットの有無 | <br> ## IAMポリシー   #### IAMポリシーの分類 | IAMポリシーの分類 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| 特徴 | |:---------------------|:----------------| | 管理ポリシー | 複数のIAMユーザ / グループ / ロールにアタッチできる。<br>それぞれ最大10までの管理ポリシーをアタッチ可能 | | -AWS管理ポリシー | AWSにより管理されているポリシー | | -カスタマー管理ポリシー | IAM管理者が作成するポリシー | | インラインポリシー | 個々のIAMユーザー/グループ/ロールに直接設定するポリシー。共有不可 | <br> #### IAMポリシーに設定する権限 アクセス権限はJSON形式で記載し、Effect / Action / Resource / Conditionを設定 ``` { "Effect":"Allow",#Effect:AllowまたはDeny "Action":[    #Action:対象となるAWS操作(*指定可、s3:Delete*など) "s3:PutObject", "s3:GetObject", "s3:DeleteObject" ], "Resource":"arn:aws:s3:::*/*", #Resource:対象となるAWSリソース(EC2,S3など) "Condition":{  #Condition:有効になる条件 "IpAddress":{"aws:SourceIp":"172.31.1.0/24"} } } ``` ARN(Amazon Resorce Name)で指定するリソースを記述. ARNとは、AWSリソースに対して一意に設定される名前 ![](https://i.imgur.com/1hBwwou.png) <br> Resourceを「*」で指定した場合、対象のAWSサービスのすべてのリソースに対してEffectで指定した権限が有効になるため、書き込みを含む権限を与えるときには注意が必要。 <br> #### 有効な権限の算出方法 明示的 Deny #### IAMポリシーによるアクセス権限の評価例 | | パターン1 | パターン2 | パターン3 | パターン4 | |:-------|:-------|:-------|-------|:-------| | グループA:Allow | 設定なし | アタッチ | アタッチ | アタッチ | | グループB:Allow | 設定なし | 設定なし | アタッチ | 設定なし | | ユーザインライン<br>ポリシー:Deny | 設定なし | 設定なし | 設定なし | 設定あり | | 評価結果 | Deny | Allow | Deny | Deny | | 備考 | なにもポリシーが<br>設定されていない。 | グループAで<br>Allowが設定<br>されている。| グループBで<br>Denyが<br>設定されている。 | ユーザーのインライン<br>ポリシーでDenyが<br>設定されている。 | #### リソースベースのポリシー AWSリソースに設定するポリシー #### リソースベースのポリシーをS3バケットに指定した例 ``` { "Effect":"Allow", "Principal":"*", #Principal:対象となるAWSアカウント、ユーザー "Action":[    #Action:対象となるAWS操作 "s3:PutObject", "s3:GetObject" ], "Resource":"arn:aws:s3:::Mybucket/*", #Resource:対象となるAWSリソース "Condition":{  #Condition:有効となる条件 "IpAddress":{"aws:SourceIp":"172.31.1.0/24"} } } ``` この例では、IPアドレス172.31.1.0/24からの匿名によるS3バケット[Mybucket/]へのPutObject,GetObjectを許可する。 <br> ### IAMロール IAMロールを利用すると、AWSサービスから別のAWSサービスへのアクセスを許可することも可能になる。 ex. Lambda関数からS3バケットにオブジェクトをコピーしたい場合、Lambdaの特定の関数に対してS3バケットへの書き込み権限を持つIAMロールにアタッチすることで実現可能 EC2にIAMロールを使用すると、アクセスキーIDとシークレットアクセスキーの権限が不要となるため、キーの漏洩リスクがなくなる。 <br> ### 一時的セキュリティ認証情報 (Security Token Service (以下,STS)) IAMロールを利用する場合、STSによって一時的認証情報として、セキュリティトークン、アクセスキーID、シークレットアクセスキーが生成される。 STSの一時的セキュリティ認証情報は短時間のみ利用可能なため、外部に漏れても再利用できない。 <br> ### Switch Roleを使用した異なるアカウントの管理 自社で管理するAWSアカウント数が増えてきた場合、IAMユーザーを一元管理するAWSアカウントを用意し、ほかのアカウントをSwitch Roleを使用して管理することで、各AWSアカウントでのIAMユーザーの管理工数を削減できる。 ![](https://i.imgur.com/zklppyj.png) <br> ### IDフェデレーション(ID連携) | IDプロバイダ | AWSとの連携方法 | | ---------- | -------------------- | | SAML2.0 | IAM SAML2.0 IDプロバイダーによるIDフェデレーションが可能。<br>Active Directoryは、ADFS(Active Directory Federation Service)を<br>使用することでSAML2.0に対応するため、このIDフェデレーションが可能 | | OpenID Connect | IAM OpenID Connect IDプロバイダーによる<br>ウェブIDフェデレーションが可能。<br>例えば、FacebookやTwitterなどのOpenID Connectに<br>対応しているソーシャルIDを利用可能、これをウェブIDフェデレーションと呼ぶ | | LDAP | SAML2.0に未対応のIDプロバイダーを<br>使用する倍は、カスタムIDブローカーを開発することで<br>IDフェデレーションを実装可能 | | AD(ADFSなし) | オンプレミスでActive Directoryを使用し、<br>ADFSを使用していない場合、AWS Directory Service <br>AD Connectorを使用することで直接IDフェデレーションが可能。<br>AWS Directory Service AD Connectorがユーザ認証を<br>Active Directoryにリダイレクトすることで認証を行う | | モバイル(ソーシャルID) | モバイルアプリケーションがS3やDynamoDBなどのAWSリソースに<br>ソーシャルIDを使用してアクセスする場合には、<br>Amazon Cognitoを使用可能.<br>Amazon Cognitoは、OpenID ConnectとSAML2.0に対応している。<br>ソーシャルIDがこれらに対応していない場合には、<br>IDブローカーとして動作する。 #### SAML2.0によるIDフェデレーション ![](https://i.imgur.com/dfLB2p5.png) #### LDAPによるIDフェデレーション ![](https://i.imgur.com/3sHTCgT.png) <br> # VPC VPCとは、Amazon Virtual Private Cloudの略 <br> ## VPCの設定 手順として、①VPC作成→②サブネット作成→③ルートテーブル/ゲートウェイ作成→④セキュリティ設定の順で行う。 ※ ネットワーク要件により、エンドポイントやVPCピアリングなどの作成が必要 <br> ### ① VPC作成 リージョンをまたいでVPCを作成することは不可 VPCのIPアドレスレンジ CIDR(Classless Inter-Domain Routing) ブロックの16~28の範囲で設定可能 CIDR ブロック (10.20.5.0/24)の例 * 3オクテッド目(00001010 00100100 00000101)までがネットワークアドレス * 4オクテッド目(0000000 )がホストアドレス部 <br> ### ② サブネット作成 AZ(アベイラビリティゾーン)毎に1つ以上のサブネットを追加する。 ※ 1つのサブネットは複数のAZにまたがって設定不可 <br> ### VPCのCIDRブロックが16の場合のサブネット数とIPアドレス数 | サブネットマスク | サブネット数 | サブネット1当たりのIPアドレス数 | | -------- | -------- | -------- | | 18 | 4 (=$2^{2}$) | 16379 (=$2^{14}-5$) | | 24 | 256 (=$2^{24-16}$) | 251 (=$2^{8}-5$) | | 28 | 4096 (=$2^{28-16}$) | 11 (=$2^{4}-5$) | <br> ### 利用ができないホストアドレス | ホストアドレス &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| 分類 | 用途 | | -------- | -------- | -------- | | .0 | 標準仕様 | ネットワークアドレス | | .1 | AWS独自仕様 | VPCルータ | | .2 | AWS独自仕様 | DNSサービス | | .3 | AWS独自仕様 | AWSで予約 | | .($2^{ホストアドレス部のビット数}-1$) | 標準仕様 | ブロードキャストアドレス※ | ※ ホストアドレス部のビット数は,たとえばCIDRブロックが/28の場合,4(=32-28)であるため、ブロードキャストアドレスは15(=$2^4-1$)となる。 #### サブネットの種類 * プライベートサブネット=インターネットへのルートが無 * パブリックサブネット=インターネットへのルートが有 <br> ### ③ ルートテーブル / ゲートウェイ作成 各サブネットに関連づけられるルートテーブルを作成 サブネットを出るアウトバウンドトラフィックは、ルートテーブルにより送信先を指定 <br> * インターネットゲートウェイ(Internet Gateway:IGW)<br>インターネットと通信するために必要なゲートウェイ * 仮想プライベートゲートウェイ(Virtual Private Gateway:VGW) <br>ほかの拠点とインターネットVPNを接続する際にVPC側で作成するゲートウェイ * カスタマーゲートウェイ(Customer Gateway:CGW)<br>VPCとインターネットVPNを接続する際にクライアント側の拠点で作成するゲートウェイ * NATゲートウェイ(NAT Gateway)<br>プライベートサブネットからインターネットにアクセスする際にプライベートIPアドレスからパブリックIPアドレスにアドレス変換を行う場合に利用するゲートウェイ。また、インターネットからはプライベートサブネットにアクセスしないようすることも可能 <br> <br> ### VPC, AZ, サブネットの関係図 ![](https://i.imgur.com/kJqEEy6.png) サブネットの種類は、サブネットのIGWが設定されているかどうかで決定。 * 送信先を0.0.0.0/0とし、特定のサブネットのルートテーブルのターゲットに作成したIGWを指定することで、パブリックサブネットとなる。 * IGWを指定しないサブネットはプライベートサブネットとなる。 <br> ### ④ セキュリティ設定 ( セキュリティグループ / ネットワークACL の設定) AWSでは、ファイアウォールを2つの機能を用いて設定 * セキュリティグループ<br>インスタンスタンス単位で許可する通信のみをインバウンドとアウトバウンドのトラフィックについて設定。ステートフルであるため、戻りのトラフックの設定は不要。すべての設定が適用される。 * ネットワークACL(アクセスコントロールリスト)<br>サブネット単位で許可/拒否する通信をインバウンドとアウトバウンドのトラフィックについて設定。ステートレスであるため、戻りのトラフィック設定も必要。番号の順番通りにルールが適用される。 | 項目 | セキュリティグループ | ネットワークACL | | -------- | -------- | -------- | | 設定単位 | インスタンス | サブネット | | 許可/拒否単位 | 許可のみ | 許可もしくは拒否 | | ステートレス/ステートフル | ステートフル | ステートレス | | ルール適用 | すべて | 番号の順番どおり | ファイアウォールはセキュリティグループの設定のみでも十分可能だが、たとえば特定のトラフィックをサブネット全体で拒否する場合などサブネット単位で一律にトラフィックを制御する際にはネットワークACLを利用するのが有効 <br> ## エンドポイントの作成 VPC内のEC2インスタンスからS3にインターネットを経由せずにVPC内から直接アクセスするには,VPCエンドポイントを経由することが必要。 エンドポイントを作成する方法<br> * ゲートウェイ型 <br>VPC内部から直接サービスと通信が実行 * インターフェイス型 <br>サブネットにエンドポイント用のIPアドレスが生成され、そのIPアドレスに向けた通信がパブリックIPアドレスを持つサービスに内部的に転送される。 <br> ## ピア接続 2つのVPC間を接続する方法。 異なるAWSアカウントのVPC間でも接続でき、リージョンをまたいだ設定も可能。<br> これによって通信できるのは直接ピア接続を行っているVPCのみ。2ホップ以上の通信(ピア先VPCが接続しているほかのVPCへの通信)は不可