はじめに

プロ試験を目指すにあたりこの記事を読むことにした
https://dev.classmethod.jp/articles/2018-aws-re-entering-backup-and-dr/

ぼくのかんがえたさいきょうのDRせんりゃく。

DRとAWS

コスト・柔軟性・アジリティの低さが課題

可用性とDRレベルの選定

可用性レベル	復旧時間(RTO)	DRレベル
継続的な可用性	常時-15秒	ミラーサイト
HA(高可用性)	15-30分	ホットサイト
スタンバイシステム	30minute-72hour	ウォームサイト
データ復旧	72hour-	コールドサイト

一般的な復旧までの道のり

-------RPO--------

バックアップ
- データバックアップ

-------RTO--------

災害発生
- 復旧対象の確認
- バックアップ対象の状況確認
- テープの郵送とインフラ再構築
アプリ復旧
- 消失トランザクションの復旧
- データ復旧
- バックアップシステム上のアプリの開始
サイト切り替え(フェイルオーバー)
- バックアップシステムへトラフィックをリダイレクト
- 別サイトでシステム運用の再開
SLA達成
- メインサイトの復旧

Backup&DR アーキテクチャパターン

クラウドバックアップ&リストア
- ストレージの格納先をクラウド
- データのリストア先はオンプレミス環境に実施
- RPOはバックアップ取得時点になる
クラウドコールドスタンバイ
- ストレージの格納先をクラウド
- データのリストア先はクラウド上に実施
  - 事前にクラウド側にシステムイメージの配置が必要
- RPOはバックアップ取得時点になる
クラウドウォームスタンバイ
- クラウド側にサイトを立ち上げレプリケーションを常時行う
  - フロント系は停止
  - バックエンドは最小構成で稼働
- DCとクラウド間で専用線もしくはVPNが必須
- RPO＆RTOの向上
クラウドマルチサイトホットスタンバイ
- 災害時はシステムの切り離しのみでOK
- 常時本番環境を稼働
- 専用線もしくはVPNが必須

AWSリソースを活用したDR構築のまとめ

学習

サンプル問題の直しを行う。
https://d1.awsstatic.com/Train%20%26%20Cert/docs/AWS_certified_solutions_architect_professional_examsample.pdf

1

あなたの会社にあるオンプレミス環境のコンテンツマネージメントシステムは以下のアーキテクチャを採用しています。

アプリケーション層 – JBoss アプリケーションサーバー上で動作する Java コード
データベース層 – Oracle RMAN バックアップユーティリティを使用して定期的に S3 にバックアップされ
る Oracle データベース
静的コンテンツ – iSCSI インターフェース経由でアプリケーションサーバにアタッチされた、Gateway
Stored Volume の Storage Gateway に格納された 512GB のコンテンツ

AWS をベースとした災害対策戦略を想定した場合、最も優れた RTO を得られるのものはどれですか?

EC2 に Oracle データベースおよび JBoss アプリサーバーをデプロイする。 Amazon S3 から RMAN
Oracle バックアップを復元する。Storage Gateway から静的コンテンツの EBS ボリュームを生成し、JBoss
EC2 サーバーにアタッチする
RDS で Oracle データベースをデプロイする。EC2 に JBoss アプリサーバーをデプロイする。 Amazon
Glacier から RMAN Oracle バックアップを復元する。Storage Gateway から静的コンテンツの EBS ボリュ
ームを生成し、JBoss EC2 サーバーにアタッチする。
EC2 に Oracle データベースおよび JBoss アプリサーバーをデプロイする。 Amazon S3 から RMAN
Oracle バックアップを復元する。Amazon EC2 で稼働する AWS Storage Gateway を iSCSI ボリュームと
して JBoss EC2 サーバにアタッチして、静的コンテンツを復元する。
EC2 に Oracle データベースおよび JBoss アプリサーバーをデプロイする。 Amazon S3 から RMAN
Oracle バックアップを復元する。 Amazon EC2 で稼働する AWS Storage Gateway-VTL から静的コンテ
ンツを復元する。

RTOとRPO

https://techtarget.itmedia.co.jp/tt/news/1901/15/news08.html
RPO=どの程度のデータ量を失っても構わないかを決める。
RTO=ダウンを許容できる最大時間

Storage Gateway

ボリュームは AWS Storage Gateway サービスが管理する Amazon S3 バケットに保存されます。AWS Storage Gateway を介した I/O オペレーションでボリュームにアクセスできます。Amazon S3 API の操作を使用してボリュームに直接アクセスすることはできません。Amazon EBS スナップショットの形で使用できる、ゲートウェイボリュームのポイントインタイムスナップショットを作成できます。Amazon EBS スナップショットは、Storage Gateway ボリュームか EBS ボリュームのいずれかに変更できます。ファイルゲートウェイを使用して、S3 内のデータをネイティブに操作します

Amazon EBS スナップショットの形で、ゲートウェイボリュームのポイントインタイムスナップショットを作成できます。ボリュームのスナップショットを新しい Amazon EBS ボリュームの開始点として使用し、それを Amazon EC2 インスタンスにアタッチすることができます。このアプローチを採用すると、データの処理にオンデマンドのコンピューティング性能がさらに必要になった場合や、災害対策のための代わりのキャパシティーが必要な場合に、オンプレミスのアプリケーションから Amazon EC2 で実行しているアプリケーションに、データを容易に供給できます。

オンプレミスでボリュームデータが保存される保管型ボリュームの場合、Amazon S3 にあるスナップショットは、耐久性に優れたオフサイトバックアップとなります。バックアップの復元が必要な場合は、スナップショットから新しいボリュームを作成できます。ボリュームのスナップショットを新しい Amazon EBS ボリュームの開始点として使用し、それを Amazon EC2 インスタンスにアタッチすることもできます。

要はスナップショットからEBSボリュームにしEC2にアタッチしろということ

答えはA
DR

2

ある ERP アプリケーションが、1 つのリージョンで複数のアベイラビリティーゾーンにまたがってデプロイされています。
障害が発生した場合、RTO は 3 時間未満、RPO は 15 分である必要があります。お客様は、約 1.5 時間前にデータ破損が
発生していたことに気づきました。このような種類の障害が発生したときにこの RTO と RPO を達成するために使用でき
るのは、どの DR 戦略ですか?

15 分ごとに Glacier に DB バックアップを保管すると共に、 Amazon S3 に 5 分ごとのトランザクションロ
グを保管する。
2つのアベイラビリティーゾーンの間で同期型データベースのマスター/スレーブレプリケーションを使用する。
Amazon S3 への 1 時間ごとの DB バックアップ取得を行うと共に S3 に 5 分ごとのトランザクションログを
- これが正解。S3をファーストチョイスとしてストレージとして選定することがDR問題には適している
  保管する。
Amazon EC2 のインスタンスストアボリュームへ 1 時間ごとに DB のバックアップ取得を行うと共に
Amazon S3 に 5 分ごとのトランザクションログを保管する。
- バックアップを揮発性のストアボリュームに保持させるのはあり得るのだろうか？
- 可能なのではあるがなしだろう

S3

迅速取り出しでは、アーカイブのサブセットが緊急に必要になった場合にデータにすばやくアクセスできます。250 MB を超えるような最大サイズのアーカイブを除き、[Expedited] 取り出しを使用してアクセスするデータはすべて、通常は 1～ 5 分以内に使用可能になります。迅速取り出しには、オンデマンドとプロビジョニング済みの 2 種類があります。オンデマンドリクエストは、1～5 分以内に取り出しを完了できる場合に行ないます。プロビジョニング済みリクエストでは、必要に応じて、迅速取り出しで利用できる取り出し容量を確保します。

DBバックアップは250MB以上である可能性が高いため、迅速取り出しは使用できない。そのため、通常取り出しを選択するが、3-5時間はRTOで許容されていないのでダメ。

RDS

DB インスタンスをマルチ AZ 配置として実行することの主な利点は、データベースの耐久性と可用性を向上することです。マルチ AZ 配置によって高められる可用性と耐障害性は、本番環境に最適です。
DB インスタンスをマルチ AZ 配置として実行すると、万一 DB インスタンスコンポーネントに障害が発生した場合や、特定のアベイラビリティーゾーンで可用性が失われた場合でも、データの安全が守られます。

RZレベルには対応できない。AZレベルでのDRではこれがベストではないだろうか。

3

会社のマーケティング担当ディレクターから、"何気ない親切" と思われる善行を目にしたら 80 文字で要約して投稿できる
モバイルアプリケーションを作成するように依頼されました。できるだけ幅広い種類のスマートフォン、ブラウザ、タブレッ
トで動作するように、JavaScript でアプリケーションを記述することにしました。投稿された要約を保存するため、アプ
リケーションから Amazon DynamoDB にアクセスさせる必要があります。プロトタイプの初期テストでは、使用状況に
大きなスパイクはないことが分かっています。このアプリケーションで最もコスト効率が高く、スケーラブルなアーキテクチ
ャとなるのはどの選択肢ですか?

EC2 インスタンス上で Security Token Service の Token Vending Machine (TVM)を使用して、 JavaScript クラ
イアントに対し一時的な認証情報を提供し、Amazon Identity and Access Management (IAM) ユーザーにマッピ
ングされ、DynamoDB の入力および S3 への GET を許可する署名付き認証情報を提供する。ウェブサイトとして有
効にした S3 バケットからモバイルアプリケーションを配信し、クライアントにより DynamoDB が更新される。
- EC2インスタンス上で何かしている時点できつい
- フェデレーション使おうよ
Amazon、Google、または Facebook のようなウェブ認証プロバイダにアプリケーションを登録し、そのプロバイ
ダ用の IAM ロールを作成し、IAM ロールには S3 への GET および DynamoDB の入力を許可する権限を設定す
る。ウェブサイトとして有効にした S3 バケットからモバイルアプリケーションを配信し、クライアントにより
DynamoDB が更新される。
Security Token Service の Token Vending Machine（TVM）を使用して、JavaScript クライアントに対し一時
的な認証情報を提供し、IAM ユーザーにマッピングされ、DynamoDB の入力を許可する署名付き認証情報を提供
する。負荷分散され、オートスケール設定された Apache EC2 インスタンスからモバイルアプリケーションを配信
する。 EC2 インスタンスは、DynamoDB の入力を許可する IAM ロールを設定し、サーバーにより
DynamoDB が更新される。
アプリをEC2から配布はあかん
フェデレーション使おうよ
負荷分散されていないのでマイナス１ポイント
Amazon、Google、または Facebook のようなウェブ認証プロバイダに JavaScript アプリケーションを登録し、
そのプロバイダ用の IAM ロールを作成し、IAM ロールに DynamoDB の入力を許可する権限を設定する。負荷分
散され、オートスケール設定された Apache EC2 インスタンスからモバイルアプリケーションを配信する。EC2
インスタンスは、DynamoDB の入力を許可する IAM ロールを設定し、サーバーにより DynamoDB が更新され
る。
- アプリをEC2から配布は骨が折れる
- cloudfrontかませたい

今回のアーキテクチャは以下と考えられる。

AWSとフェデレーション

そもそも「フェデレーション」とは

フェデレーションという用語は、インターネットの各サービスのユーザー認証の連携のことを指します。
IDフェデレーションといった用語が使われることが多く、既に認証が済んだユーザーIDを使って、別のシステムにアクセス出来るようにする仕組みそのものを指しています。

AWS Cognitoを利用したIDフェデレーション

このフェデレーションで最も広く使われているプロトコルがSAML 2.0という方式です。

SAML 2.0によるIDフェデレーション

ADFS

Microsoftが開発したソフトウェアコンポーネントであるActive Directoryフェデレーションサービスは、Windows Serverオペレーティングシステムで実行して、組織の境界を越えて配置されたシステムおよびアプリケーションへのシングルサインオンアクセスをユーザーに提供

FacebookやTwitterなど、パブリックサービスを利用したIDフェデレーション

ユーザー認証のためのウェブフェデレーテッド ID の使用

まず、アプリケーションがサポートするプロバイダーにアプリケーションを登録する必要があります。次に、IAM ロールを作成し、そのアクセス許可を設定します。作成した IAM ロールは、それぞれの ID プロバイダーを介して自分に設定されたアクセス許可を付与するのに使用されます。

AWS Serverless Multi-Tier Architectures

三層構造概要

モバイルアプリケーションの三層構造は以下となる。

プレゼンテーション層
- mobile
ロジック層
- apigatewayとlambdaを使う
データ層
- ElasticCash
- RDS
- Dynamo

Mobile Back End

Amazon S3 Hosted Website

Microservices Environment

一般に、マイクロサービス環境では次のことを可能にしてくれる。
困難：新しいマイクロサービスを作成するたびにオーバーヘッドが繰り返される、問題
サーバー密度/使用率の最適化、複数バージョンの実行の複雑さ
同時に複数のマイクロサービス、およびクライアント側コードの急増
多くの個別のサービスと統合するための要件。

しかし、このアーキテクチャだと上記の課題を打破してくれる。最終形態。

[AWS初心者向けWebinar] AWSを活用したモバイルアプリの開発と運用

4

ユーザーにとって機密性の高い情報を取得して表示するウェブサイトを構築しています。サイトが受信するトラフィックの量
はわかっていて、上下しないと予想されます。このサイトでは、SSL を活用してクライアントとウェブサーバー間の通信を
保護します。サイトの性質のゆえに、SSL プライベートキーのセキュリティについて非常に懸念しており、キーが誤って、
または意図的に環境外に移動されることがないようにしたいと思っています。また、サイトで表示されるデータは暗号化され
た EBS ボリュームに保存されますが、ウェブサーバーのログに機密情報が含まれることも懸念しているため、自社の従業
員以外には復号化できないようにログを保存する必要があります。すべての要件を満たすのは次のうちどのアーキテクチャです
か?

Elastic Load Balancing を使用して、トラフィックを一連のウェブサーバーに分散する。SSL プライベートキーを保護
するため、キーをロードバランサーにアップロードして、SSL トラフィックの負荷を軽減するようにロードバランサーを
設定する。ウェブサーバーのログを、ランダムに生成された AES キー（共通鍵暗号方式）を使用して暗号化されているエフェメラルボリュ
ームに書き込む
キーをアップロードがダメ
Elastic Load Balancing を使用して、トラフィックを一連のウェブサーバーに分散する。ロードバランサーで TCP
ロードバランシングを使用して、起動時にプライベート Amazon S3 バケットからプライベートキーを取得するよ
うにウェブサーバーを設定する。Amazon S3 サーバー側の暗号化を使用して、ウェブサーバーのログをプライベー
ト Amazon S3 バケットに書き込む。
　 * キーをもっと大事にして！
Elastic Load Balancing を使用して、トラフィックを一連のウェブサーバーに分散する。TCP ロードバランシング
を実行するようにロードバランサーを設定する。AWS CloudHSM を使用してウェブサーバー上で SSL トランザク
ションを処理し、Amazon S3 サーバー側の暗号化を使用して、ウェブサーバーのログをプライベート Amazon S3 バ
ケットに書き込む
　* キーの取り扱い〇
　* ログのカギがHSMより流出しやすいからダメ
Elastic Load Balancing を使用して、トラフィックを一連のウェブサーバーに分散する。 TCP ロードバランシングを
実行するためにロードバランサーを設定しする。AWS CloudHSM を使用してウェブサーバー上で SSL トランザクショ
ンを処理し、ウェブサーバーのログを、ランダムに生成された AES キーを使用して暗号化されているエフェメラルボ
リュームに書き込む。
- SSLアクセラレーション。ログを自社以外に複合できないようにするためにはHSMのカギで複合するから正解

AWS CloudHSM の SSL/TLS オフロードでウェブサーバーのセキュリティを向上させる

ウェブサーバーおよびそのクライアント (ウェブブラウザ) では、Secure Sockets Layer (SSL) または Transport Layer Security (TLS) を使用できます。これらのプロトコルは、インターネット経由でウェブページまたは他のデータを送受信するために、ウェブサーバーのアイデンティティの確認と、安全な接続の確立を行います。これは一般に HTTPS として知られています。このウェブサーバーでは、パブリック/プライベートのキーペアと SSL/TLS パブリックキー証明書を使用して、各クライアントとの HTTPS セッションを確立します。このプロセスでは、ウェブサーバーで大量の計算が必要になりますが、一部の計算は AWS CloudHSM クラスターの HSM にオフロードできます。このプロセスは、SSL アクセラレーションと呼ばれることもあります。オフロードにより、ウェブサーバーのプライベートキーを HSM に保存することで、ウェブサーバーの計算の負担が軽減され、セキュリティが強化されます。

SSL/TLS オフロードが AWS CloudHSM と連携する仕組み

HTTPS 接続を確立するため、ウェブサーバーはクライアントとハンドシェークプロセスを実行します。次の図に示すように、このプロセスの一環として、サーバーはいくつかの暗号化処理を HSM にオフロードします。

そもそも　デジタル(SSL)証明書とは

https://milestone-of-se.nesuke.com/sv-advanced/digicert/digital-certification-summary/

1 クライアントがDNSサーバにクエリ
2 返答されたIPとクライアントがTCPセッションを張る
3 TLSネゴシエーション中にデジタル証明書がクライアントに示される。
4 クライアントは提示された証明書のコモンネームと、ブラウザに入力した URL の FQDN (『https://』と『次の/』の間の文字列) が一致するかどうかを確認
5 一致かつ証明書自体が信頼できると判断された場合、サーバ認証される
6 証明書に含まれている公開鍵でクライアント側の共通かぎを暗号化し、パケットを送信。サーバ側は秘密鍵で暗号化された共通鍵を複合化し、複合化された共通鍵を使うことによりHTTPSが実現
- クライアントはサーバから送信されたハッシュ化データとデジタル署名の 2 つをチェックしてデータに差異がないか確かめる。

証明書の信頼について

基本的にWebサーバが所持している鍵は中間証明書に含まれていた秘密鍵と公開鍵。厳密にはWebサーバにインストールするのはデジタル証明書と秘密鍵なので、SSLネゴシエーションを行う際にpemから公開鍵を生成しているのだろう。

一般的な発行手順

1 Linux サーバの OpenSSL (もしくはその他の機器) の証明書発行コマンド等で、発行者情報や、デジタル証明書を利用したい機器のホスト名 (コモンネーム＝FQDN) 等を入力し実行すると、CSR と秘密鍵が発行されます。CSR の詳細については後述します。
- CSR とは証明書発行要求 (Certificate Signing Request) と呼ばれるもので、これを生成する際に、秘密鍵と公開鍵も作られます。
2 秘密鍵は他人に極力知られないようにしておき、CSR は認証局にメール等で送付します。(デジタル証明書本体は、インターネットに公開して使うのが一般的であり、その元となる CSR は公開されても構わない情報になります。
3 認証局が自身の秘密鍵を使って、CSR に電子署名を付与します。その結果が「デジタル証明書」になります。このデジタル証明書を CSR 送信者へ送り返します。
- CSR には公開鍵が含まれており、この CSR を中間認証局に送り、中間認証局の秘密鍵で生成した電子署名 (CSR をハッシュ化したものを秘密鍵で暗号化) を CSR の末尾に付け加えることでデジタル証明書が出来上がります。
4 CSR 送信者は秘密鍵とデジタル証明書をセットで、利用したい機器にインストールします。(CSR を発行した機器とは別でも構いません)

中間証明書の必要性と、扱う上での注意点

中間証明書は PC に含まれていないことが多く、このような連結操作をしてからインストールしないとルート証明書の検証まで辿り着かず、証明書エラーが表示されてしまうケースがあります。

ルート証明書や中間証明書のPCへのインストール状況確認方法、およびインストール方法

中間証明書やルート証明書が Windows にインストールされているかどうかを確認するには、IE の「インターネットオプション」⇒「コンテンツ」⇒「証明書」から、[中間証明機関] (中間証明書の場合) や [信頼されたルート証明機関] (ルート証明書の場合) をクリックします。

SSL/TLS オフロードが AWS CloudHSM と連携する仕組み

1 ハンドシェイク
2 TLSネゴシエーション
3 TLSセッションのためのプリマスタシークレットを作成
4 サーバじゃHSMにプリマスタシークレットを転送、HSMが秘密鍵で複合してサーバに返す
5 HTTPSでおしゃべり

5

思いのほか時間かかります。明日で終わりたい。