AWS認定学習記録-VPC-VPCの概要

春が近づいているのか寒暖の差があって体調管理しずらいここ最近です。
寒い日は鍋が食べたくなるので冷え込む金曜は鳥団子鍋を作ろうかなぁと レシピ検討中でございます。

今回のテーマ：VPCの概要

VPC(Virtual Private Cloud)とは

• AWSクラウドのネットワークからユーザー専用の領域を切り出してくれる仮想ネットワークサービス
• 任意のIPアドレス範囲を選択して仮想ネットワークを構築
• サブネットの作成、ルートテーブル/ネットワークゲートウェイの設定など仮想ネットワーキング環境を制御
• 必要に応じてクラウド内外のネットワーク同士を接続
• オンプレイミス環境との接続オプションが利用可能(インターネット経由、VPC/専用線(Direct Connect))
• 単一、複数のAZにまたがった領域(AZ)でネットワーク構築が可能

サブネットとVPC

• 最低1つのAZ内に1つのVPCとサブネットがデフォルトで構築される

会社で利用する場合、
アーキテクチャを実装・管理するため、
デフォルトのものを使用しないことが一般的になります。

VPCの設定(デフォルトVPC)

AWSアカウントを作成すると自動的に各リージョンに1つのデフォルトVPCとデフォルトサブネットが生成されます。
デフォルトの以下となります。

• サイズ/16のIPv4CIDRブロック(172.31.0.0/16)のVPCが作成される
• 各AZにサイズ/20のデフォルトサブネットが作成される
• デフォルトサブネットで作成されたアドレスのいくつかはAWSの予約アドレスとして使用される
• インターネットゲートウェイが作成され、デフォルトVPCに接続される
• デフォルトのセキュリティグループが作成され、デフォルトVPCに関連付けられる
• デフォルトのネットワークアクセスコントロールリスト(ACL)が作成されデフォルトVPCに関連付けられる
• デフォルトVPCを備えたAWSアカウントにはデフォルトDHCPオプションセットを県連つけられる
• パブリックとプライベートのDNSホスト名が付与される。

VPCの設定

VPCの設定できる内容と実装する領域

• 1つのパブリックサブネットを持つVPC
• パブリックとプライベートサブネットを持つVPC
• パブリックとプライベートサブネットをおよびハードウェアVPNを持つVPC
• プライベートサブネットのみでハードウェアVPNアクセスを持つVPC

cf)

パブリックとプライベートサブネットをおよびハードウェアVPNを持つVPC

Site-to-SiteVPCを構成する際に使用する項目

新規VPCの設定概要

• 1.VPCを作成(CIDR設定)
• 2.サブネットを作成
• 3.インターネット経路を設定(Gatewayの設定)
• 1. VPCへのトラフィック許可の設定

cf)

VPCで使用できるサブネットの範囲

「/16」～「/28」の間で飲み使用可能

CIDRで予約されているIPアドレス(/24の場合)

ホストアドレス	用途
.0	ネットワークアドレス
.1	VPCルータ
.2	Amazonが提供するDNSサービス
.3	AWSで予約されているアドレス
.255	ブロードキャストアドレス

AWSで使用するサブネット

CIDR範囲で分割したネットワークセグメントで、AWSのサブネットは「パブリックサブネット」、「プライベートサブネット」が存在します。
また、VPC内に複数設定でき1つのAZを指定して配置が可能です。

• パブリックサブネット：トラフィックがインターネットゲートウェイにルーティングするサブネット
• プライベートサブネット：インターネットゲートウェイのルートがないサブネット
• 1つのVPCあたりのサブネット作成上限数のデフォルトは200個までとなります。
• パブリックおよびプライベートサブネットの推奨値は「/24」がAWSの公式概要となります。

VPC外部接続

VPCの外部リソースとの接続する際、別のAWSリソースを組み合わせることで実装します。
また、接続する手法としてパブリックサブネットのAWSネットワーク(EC2など)かエンドポイント(S3)を利用し接続を実現します。
以下は、パブリックサブネットとプライベートサブネットを設けた場合での実装概要をまとめます。

パブリックサブネットからインターネットに接続する場合、インターネットゲートウェイが必要

プライベートサブネットからインターネットに接続する場合、パブリックサブネット内にNATゲートウェアを設置し、 NATゲートウェイからインターネットゲートウェイへルーティングが必要

概略図は以下のようになります。

インターネット経路の設定

方法：ルートテーブルとCIDRアドレスでルーティングを設定

手順概要：

• ルートテーブルでパケットの行先を設定
• VPC内はCIDRアドレスでルーティングを実装

VPC設計ポイント

• 将来の拡張性を見据えたアドレッシングや他ネットワークとの接続性を考慮する
• CIDRは既存のＶＰＣ、社内で使用しているDCやオフィスと被らないアドレス帯を設定し、システム構成の将来像を考慮しながら計画する
• VPC構成は自社業務に合わせてVPC単一ではなくVPC全体の関係性を考慮する
• 組織とシステム境界からVPCをどのように分割するか考慮する
• 複数のAZを利用し可用性の高いシステムを構築を検討する
• サブネットは大きいサブネットを使用し、パブリック/プライベートサブネットへのリソース配置をインターネットアクセス可否から検討する
• セキュリティグループを使いリソース感のトラフィックを適切に制御する
• 運用を補助するツールも有効活用し、VPC Flow Logsを使ってモニタリングできるようにする

AWS認定学習記録-VPC-サブネットマスクとサブネット

本日は2本目の投稿となります。

今回のテーマ：サブネットマスクとサブネット

ネットワークの範囲

機器がネットワークを定義している方法とは何か整理

• ネットワークの範囲を定義
• ネットワークの範囲：IPアドレスの利用可能な範囲
• IPアドレスとサブネットマスクが利用可能な範囲
• 概略図

用語：

• IPマスカレード

-IPアドレスを変換することで1つのIPアドレスで通信できる技術
-ポート番号を変換することで、複数のプライベートIPからグローバルIPに接続できる仕組み
-別名：NAPT(Network Address Port Translation)

• NAT

IPアドレスを異なるIPアドレスに変換するので、
ローカルIPアドレスをグローバルIPに変換してインターネットへ接続

IPアドレスとサブネットマスク

• IPアドレスは3桁(０~255)×4つの組み合わせで各桁が8桁のバイナリ値の集合を表す
  概略図は以下のようになります。

• サブネットマスクはIPアドレスの表記の後ろに「/数値」が付与される

CIDR(Classless Inter-Domain Routing)

• サブネットマスクの値を設定し、同じネットワークでとして扱うIPアドレスの個数を調整できるIPアドレスの設定方法
• 2進数表記にした際サブネットが指定する数が利用できないようにロックされ変更不可
• ロックされていない桁数分のビット間が有効なIPアドレスとして使用可能

概略図

ネットワーク部とホスト部

• ネットワーク部：サブネットマスクによって固定れる範囲
• ホスト部：利用可能な範囲

サブネットマスクとIPアドレスの組み合わせ

サブネットマスク	サブネットあたりのIPアドレスの数
/18	16384
/20	4096
/22	1025
/24	256
/26	64
/28	16

サブネットによるグループ化

• あくまで事例的な観点ですが建物のフロア単位や部署ごとにサブネットを定義し管理しやすくする

まとめ

• サブネットマスクを設定することで、同じネットワークとして扱うIPアドレスの範囲を指定できる
• IPアドレスの範囲のことをCIDR(サイダー)と呼ぶ
• CIDRを設定しプライベートネットワークをサブネットに分割できる。

AWS認定学習記録-VPC-IPアドレスの基礎

近隣の公園など散策するのが趣味なので、 サイクリングがてら公園散策し梅が見ごろでしたのでいい気分転換になりました。

今回からは新しいテーマのVPC(Virtul Pravate Network)の学習記録となります。
その中のコンテンツとしては下記になります。

VPCで学ぶコンテンツ

• IPアドレスの基礎
• サブネットマスクとサブネット
• VPCの概要
• VPCを構築
• パブリックサブネットを作成
• プライベートサブネットを作成
• 通信プロトコルとOSI参照モデル
• セキュリティグループとネットワークACL
• ネットワークACLの設定
• NATゲートウェイの利用
• VPC間との接続
• VPCエンドポイントの利用
• VPCぴあリング接続の構成
• Transit GateWayの構成
• VPC Flow Logs

今回のテーマ：IPアドレスの基礎

IPv4アドレス

• ネットワーク機器やWEBサイトなどの場所を特定するためにIPアドレスを利用
• ICANN(アイキャン)という非営利団体が管理
• 重複が許されない32ビット値データ
• IPアドレスの利用範囲「0.0.0.0～255.255.255.255」
• ネットインターフェースカードに割り当てホストからアタッチ
• 実装値は2進数となるが表記上は10進数

グローバルIPアドレスの不足

• グローバルIPアドレスIPv4は枯渇しつつある
• IPv6の普及が開始。(IPv5は試験的に作成され廃棄された)

グローバルとプライベートIPアドレス

IPアドレスはグルーバルIPアドレスとプライベートIPアドレスで使いわけ

要素	概要	利用可能なアドレス
グローバルIPアドレス	・世界で重複のない一意のIPアドレス ・インターネットプロバイダーから割りあてしてもらう	特になし
プライベートIPアドレス	・オフィスや家庭内などで自分の場所だけで利用できるアドレス ・ローカルエリアの管理者が自身でIPアドレスを管理する	10.0.0.0 ～10.255.255.255 172.16.0.0～172.32.255.255 192.168.0.0～192.168.255.255

まとめ

• IPアドレスは2進法の32ビット値で構成される
• IPv4は枯渇しつつあるため、IPv6も利用されている
• IPアドレスにはインターネットで利用可能なグローバルIPアドレスとプライベートネットワークのみで利用できるプライベートIPアドレスがある

AWS認定学習記録-IAM小テスト

確認テスト

設問1:

EC2インスタンスへIAMロールの追加や修正方法

回答：

EC2のマネ地面tのコンソールからEC2インスタンスのアクション操作によってアタッチする

設問2:

ルートアカウントが有するアカウント権限

回答：

管理者権限アクセス

設問3:

IAMの特徴で無い要素とは何か

回答：

多要素認証を利用することでパスワードなしのアクセスが可能

設問4:

パワーユーザのアクセス権限

回答：

パワーユーザーはIAM管理以外のすべてのAWSサービスへのフルアクセス権限

設問5:

IAMユーザーを作成した際のデフォルトの権限

回答：

全てののAWSサービスにアクセスする権限を有してない。 IAMユーザーの作成後にポリシーをアタッチするため

設問6:

ルートアカウントの特徴でないもの

回答：

AWS Organizationを利用した組織的な管理全般 これはルートユーザーでなくてもIAMユーザーで実施できる

設問7:

IAMエンティティ(ユーザー、グループ、ロール)が最後にAWSサービスにアクセスした日付と時刻を表示する機能

回答：

Access Advisor Last Accessd DateにIAMエンティティが最後にAWSサービスにアクセスした日付と時刻を表示

設問8:

IAMポリシーにおいてインラインポリシーの特徴

回答：

1つのプリンシパルエンティティ(ユーザー、グループ、、ロール)に埋め込まれたポリシーで、
プリンシパルエンティティにアタッチすることができる。

設問9:

IAMポリシーの記述形式

回答：

JSON

AWS認定学習記録-IAM-AWS Oraganizationsの内容と基本的な機能や役割

今回の内容でAWSのIAMに関するテーマは最後となります。

今回のテーマ：AWS Oraganizationsの内容と基本的な機能や役割

AWS Organizationsとは

複数のAWSああ訓とを利用している場合、頭語管理を逸しすることが可能

また、IAMのアクセス管理を大きな組織で実施できるマネージドサービス

IAMとの区別をするため以下のような構造

AWS Organizationsで実施できる項目

• 複数アカウントの一元管理： AWSアカウントをグループ化しポリシーを適用することによって一元的に管理

• 新規アカウント作成の自動化 コンソール/SDK/CLIでAWSアカウントを新規作成し、作成内容のログを管理

• 一括請求 複数AWSアカウントの請求を一括化

アカウントの設定

AWSアカウントのマスターアカウントを選定メンバーアカウントとしてほかのAWSアカウントを登録する

仕組み

組織単位(OU)を構成し、マスターアカウントがメンバーアカウントを管理する

例： 情報システム部(マスターアカウント所持)-広告宣伝部(メンバーアカウント)

機能セット

支払い一括代行(Consolidated Billing Only)とアカウントの全体管理(All Feature)方式のどちらかを選択

• Consolidated Billing Only

支払い代行の身を実施

ボリュームディスカウントを統合するためコストメリットがあり得る。 例：アカウントAでは一律請求。アカウントBではオンデマンドで対応などい

• All Feature

企業内の複数アカウントを統制したい場合に選択

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

組織単位(OU)内のメンバーアカウントに対し権限境界を設定する

実際の設定の仕方

手順：

1.マスターアカウントの作成
2.他のAWSアカウントをメンバーアカウントに組み込む
3.組織単位を作成
4.サービスコントロールポリシー(SCP)を設定する

1.マスターアカウントの作成

• AWSマネイジメントコンソールログイン後、検索画面よりAWS Organizationsを検索しクリック

• 組織の作成をクリック 初期ではログインしているAWSアカウントをマスターアカウントとなるため、
  マスターアカウントとしたいAWSアカウントで作業するとよいです。

2.他のAWSアカウントをメンバーアカウントに組み込む

• マスターアカウントに★が付与されたのを確認し、メンバーアカウントを追加するためにアカウント追加をクリック

• アカウントの招待をクリック

• 詳細するアカウントのメールアドレスかAWSアカウントIDを記入後、招待をクリック

• 招待されたAWSアカウントのメールアドレス先に確認メールがあるのでそちらを確認 ※Webメールの場合ですが別のアカウントを登録する際は、
  違うブラウザを起動した後でmailのリンクにあるリンクをクリック

• 招待された側でログインすると確認内容が表示されるため承認をクリック

• マスターアカウント側で登録されていることを確認

3.組織単位を作成

• アカウントの整理タグをクリック AWS Organizationsで関連しているAWSアカウントの一覧と組織が表示されてます。

• 新規組織単位をクリックし、組織単位の名前を記入後に組織単位の作成をクリック

• 作成した組織単位に関連させるため、移動させたいアカウントを選択し移動をクリック

• 移動した後の組織単位が移動されていることを確認 最上位がRootで後は組織単位に分割しAWSアカウントを所属対応となります。

4.サービスコントロールポリシー(SCP)を設定する

• ポリシーのタグをクリック

• ポリシーリストの内容を確認し、
  AWSリソースのアクセス権限の制御をしたいので、サービスコントロールポリシーをクリック

サービスコントロールポリシーとタグポリシーを設定するのが多いですが、
機能拡張によりAIサービスオプトアウトポリシーとバックアップポリシーが拡張されております。

• サービスコントロールポリシーを有効にするをクリック

• ポリシーの作成をクリック

cf)サービスアクセスコントロール(SCP)の設定項目

要素	目的	サポートされる設定
バージョン	ポリシーの処理に使用する言語構文ルールを指定	Allow,Deny
Statement	ポリシー要素のコンテナとして機能 SCPには複数のステートメントを含むことができる	Allow,Deny
Statement ID	ステートメントへの名称を付ける	Allow,Deny
Effect	SCPステートメントがプリンシパルア及びアカウント内のルートアクセスを許可/拒否を定義	Allow,Deny
アクション	SCPが許可/姜妃するAWSサービス/アクションを指定	Allow,Deny
NotAction	SCPが除外されるAWSサービス/アクションを指定	Deny
リソース	SCPが適用されるAWSリソースを指定	Deny
条件	ステートメントを実行するタイミングを指定	Deny

例： 開発部門でEC2の削除を拒否し申請しマスターアカウントを部門で削除を許可する。
今回はEC2の全操作を在宅の組織単位へ所属しているアカウントに対し拒否の設定を有効化にします。

• 実際のポリシー作成する際はポリシー名を記入します。

• アカウントとして制限したいAWSサービスを決めていきます。

• サービスでEC2と検索しクリック

• アクションでAll actionsをクリック

• リソースを追加をクリック

*AWSサービス名と[Resource type]を指定しリソースの追加をクリック

• 条件を追加をクリック

• サンプルですが現在時刻からとするので、
  条件キー：aws:CurrentTime、演算子：DateEqualsを指定し条件の追加をクリック

設定したJSONファイルがこちら

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Deny",
            "Action": [
                "ec2:*"
            ],
            "Resource": [
                "*"
            ],
            "Condition": {
                "DateEquals": {
                    "aws:CurrentTime": []
                }
            }
        }
    ]
}

• この状態でポリシーの作成をクリック

• 新しいSCPが作成できてるのを確認

• 作成したSCPを組織単位に付与するため、アカウントの整理タグをクリック

• 今回は在宅の組織単位に対し,developerのポリシーを適用(アタッチ)します。
  なので、作成してある組織単位をクリック

• 右側にあるサービスコントロールポリシーをクリック

• 適用(アタッチ)したいポリシーをクリック

• デフォルトでFullAWSAccessが有効化されているため、制限する場合はFullAWSAccessのSCPを解除(デタッチ)をクリック

• 実際の確認

AWS認定学習記録-IAM-IAMアクセスアナライザーの初期設定

最近少し計画より若干押してますが、 今年の夏目標で試験受験できればという計画なのではあります。

今回のテーマ：IAMアクセスアナライザーの初期設定

AWS IAM アクセス分析機能とは

新規または更新されたポリシーを継続的に監視し、付与されたアクセス許可を分析する際に使用します。

利用シーン

• パブリックやクロスアカウントのアクセシビリティに関するリソースポリシーを分析
• アクセス許可を調整するための監視
• 最高レベルのセキュリティ保障

詳細： AWS Identity & Access Management アクセス分析 - アマゾン ウェブ サービス

実装の仕方

• AWSマネジメントコンソール-IAM-アクセスレポート-アクセスアナライザーの順に選択し、アナライザーの作成をクリック

• 名前は任意の名称に変更し、現在のアカウントを選択し後アナライザーを作成をクリック

• 作成後の設定はアーカイブルール(操作の監視アイテム)を作成することにより有効化されます。
• 監視項目を作成するためにアーカイブルールの作成をクリック

• 名称は任意の名称にしてCreate ruleをクリック この際に接続元のIPアドレスからの接続を確認したりすることができます。

• 確認画面が表示されたら、Create anywayをクリック

• Access　Analyzerの設定は管理者の追加などの設定を登録する際に使用します。

内容としては少ないですが、 今回のテーマはここまでとなります。

AWS認定学習記録-IAM-IAMロールの権限移譲

朝起きて学習する習慣ををルーティン化できそうという感じであります。 夜はどうしてもリラックスタイムにしたいので朝勉強→仕事→リラックスというサイクルがどうもあっている気がしてます。

今回のテーマ：IAMロールの権限移譲

IAMロールの信頼ポリシー

• 監査人などに一時的な権限を委譲する際に利用

ハンズオンで実施する概要

1.アカウントAでアカウントBへ権限移譲用のロールを設定 2.アカウントBへ権限移譲用のロールをポリシーとして設定 3.2のポリシーをアカウントBのIAMユーザに設定 4.3のIAMユーザーを利用してIAMロールをスイッチしアカウントAにアクセス

実施概要の概略図

実際の適用方法

1.アカウントAでアカウントBへ権限移譲用のロールを設定

• IAM-アクセス管理-ロール-ロールの順にクリックする

• 別のAWSアカウントを選択( クロスサイトアカウント=IAMロールを適用することが合致) し別のアカウントIDを入力後、次のステップ：アクセス権限をクリック

• ポリシーは前回作成したApplication-policyを活用し次のステップ：タグをクリック

• タグは未設定で問題ないので次のステップ：確認をクリック

• ロール名は任意ですがこの場合アカウントBに対する意図を判断できるようにApplication_AcountB
• ロール名入力後、ロールの作成をクリック

2.アカウントBへ権限移譲用のロールをポリシーとして設定

• 設定前事前確認

1.アカウントAで作成したIAMロールのロールARN　(AWSリソース名)　→コピーしておくこと 2.アカウントIDをコピーしておくこと

※実施する場合は通常使用するブラウザと異なるブラウザを使用すると便利です。

• 別のAWSアカウントへログインし、IAMからポリシーを作成するをクリック

• JSONを選択しコードから作成します。
• ひな形を活用すると便利なので管理ポリシーのインポートをクリック

• AdministratorAccessを選択しインポートをクリック

• ひな形をインポート後、コードを実装します。(こういうのCI/CDの一環につながります)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect":"Allow",
            "Action":"sts:AssumeRole",
            "Resource":"arn:aws:iam::(AWSアカウントID):role/Application_AcountB"
        }    
    ]
}

• 実装後、次のステップ：タグをクリック

• タグの指定は不要なので、次のステップ：確認をクリック

• ポリシー名を指定し、ポリシーを作成をクリック

3.2のポリシーをアカウントBのIAMユーザに設定

• IAM-アクセス管理-ユーザー-ユーザーを追加をクリック

• コンソールパスワードやパスワードリセットのチェックを外して次のステップ：アクセス権限をクリック

• 既存ポリシーを直セスアタッチを選択後、先程作成したポリシーを選択し次のステップ：タグをクリック

• タグは特に指定しないため、次のステップ：確認をクリック

• 確認画面に来たら、内容を確認しユーザーの作成をクリック

• アカウントBのルートユーザからサインアウトを行います。

※ ユーザの作成が終わったらアカウントBのAWSアカウントIDを控えておくと楽です。

4.3のIAMユーザーを利用してIAMロールを選択し、アカウントBのIDを入力後に次へをクリック

• サイインインの画面に来たらIAMユーザを選択しアカウントIDをクリック

• 先程作成したユーザーでAWSマネイジメントコンソールへログイン
• ログイン後右上のIAMユーザーをクリックすると「ロールの切り替え」というメニューが増えます。

• ロールの切り替え画面に来たら、ロールの切り替えをクリック

• アクセスしたいアカウントAのAWSアカウントIDと該当ロールを入力し、ロールの切り替えをクリック

• この状態でAWSマネジメントコンソールで別のアカウントのマネジメントコンソールに切り替わった状態となります。 表示名がピンク色で設定しているので、この状態でOKとなります。