シーン1:セキュリティの監査

ForkMe!を利用して、クラウドの設計がセキュリティ上安全かどうかをチェックします。 設計者のセルフチェックや情報システム部門による監査の、品質とスピードが向上します。


ポイント:トリアージとデフォルトセーフ

ForkMe!のレポート機能は、セキュリティが事業に与える影響を簡潔に表現します。 監査不足による事業リスク、一方で過剰な監査による時間と労力の無駄をなくすには、医療現場のようなトリアージが有効です。 ForkMe!で事業影響の大きさを素早く把握し、詳細な監査の要否を判断しましょう。
そして詳細な監査が必要になったら、ForkMe!でデフォルトセーフの違反箇所を発見し、是正を勧告しましょう。 デフォルトセーフは、必要最小限の通信以外をすべてを遮断するという、シンプルかつ強力な設計ルールです。ForkMe!はその違反を発見するため、通信経路の危険性を簡潔に図示します。


ステップ1:詳細監査の要否を判定

1. レポートの「概要」タブを選択します。

2. 監査結果に、下図の「RDR_0001」エラーがないことを確認します。表示される場合は監査を中断し、設計の修正を依頼してください。 このエラーは、監査に必要な情報が設計に含まれていないことを示しています。

3. エラーの解消後、レポート中段の要約文を確認します。下の「判断基準の例」を参考に、詳細監査の必要性を判断してください。詳細監査が不要な場合、ここで監査を終了します。

判断基準の例

詳細監査が必要と判断(最優先): 要約文に「個人情報の取り扱いあり」と記載される場合(個人情報を取り扱う場合、セキュリティが事業に与える影響は常に最大です)

詳細監査が必要と判断: 要約文に「機密情報の取り扱いあり」かつ「~に接続する」と記載される場合(外部システムと連携するため、機密情報の漏洩範囲や侵害リスクが高まる可能性があります)

詳細監査不要と判断: 上のどちらにも当てはまらない場合


ステップ2:情報種別の適正化

1. 詳細監査が必要と判断した場合、詳細なレポートの「コンテキスト」タブを選択します。

2. 「システム俯瞰図」をクリックして、用途の全体像を表示します。

3. 「取り扱う情報」の情報種別が、組織やチームで規定する種別に沿っていない、あるいは混乱を及ぼす内容になっている場合は、設計者に修正を依頼してください。この種別が誤っていると、各通信経路の安全性を正しくチェックすることができません。


ステップ3:危険な通信経路の改善

1. レポートの「コンテキスト」タブを選択します。

2. 「システム俯瞰図」をクリックして図面を表示します。

3. 図中の赤矢印線(個人情報や機密情報が制限のない通信経路でやり取りされている、危険な通信経路)が以下の状態であることを確認します。そうでない場合には、設計者に是正を依頼してください。

必要最小限にとどめられている

一般的に赤矢印が許容されるのは、不特定多数にログイン機能を提供するといった通信経路です。
特にサーバ間通信は赤矢印になるべきでありません。

暗号化されたポートが利用されている

赤矢印線にカーソルをあわせ、ツールチップ内の[接続ポート]を確認してください。ポートが22/443/465/995以外の場合には通信が暗号化されていない可能性があります。

シーン2:コストの評価

ForkMe!を利用して、コストの妥当性をチェックします。 設計者のセルフチェックや企画者によるコスト評価時の、精度とスピードが向上します。


ポイント:費用対効果

ForkMe!のレポート機能は、リソースごとの費用対効果を簡潔に表現します。 コストの妥当性は単純な価格の高低ではなく、用途の重要性に見合っているかが重要です。ForkMe!を使って重要性の低い用途に無駄なコストがかかっていないかを確認し、是正しましょう。


ステップ1:効果ゼロのリソースを排除

1. レポートの「概要」タブを選択します。

2. 監査結果にエラー「RDR_0001」が表示される場合、設計者に修正を依頼してください。 このエラーは、用途が不明瞭で費用対効果の全くない(効果ゼロの)リソースが含まれることを意味しています。


ステップ2:占有リソースの無駄を改善

1. レポートの「リソース」タブを選択します。

2. リソースの「関連するコンテキスト」が一つしか表示されない場合、そのリソースは一つのコンテキストで占有されていることを意味します。一般的に関連コンテキストが多いほど果たす役割が広く効果的と考えられるため、占有リソースを見つけた場合はその妥当性を検討すべきです。
概算コストの大きさに見合う役割が割り当てられていない場合には、他リソースの共用、またはリソースのサイズダウンで無駄なコストが削減できる可能性があります。

シーン3:障害リスクの評価

ForkMe!を利用して、クラウドの設計がシステム障害のリスクをどの程度低減できているかをチェックします。設計者のセルフチェックや情報システム部門による設計アドバイスの、品質とスピードが向上します。


ポイント:レートリミットと単一障害点

ForkMe!のレポート機能は、システムにかかる負荷を簡潔に表現します。過負荷によるシステム障害のリスクを低減するには、 余裕を持った負荷の上限を想定し、その実現性を確認することが重要です。 ForkMe!で想定される負荷を確認し、クラウドベンダーや連携する外部システムに、その許容(レートリミットの緩和)を依頼しましょう。許容されない場合、設計の見直しが必要です。
また、単一リソースの問題がシステム全体に影響を及ぼす箇所は単一障害点と呼ばれ、その存在がシステム障害のリスクを高めます。可能な限り複数のリソースに処理を分散させ、リスク低減を図りましょう。ForkMe!のレポート機能は、用途ごとに処理が集中するリソースを明確にします。ForkMe!で重要な用途における単一障害点を発見し、解消を検討しましょう。


ステップ1:クラウドの上限緩和申請

1. レポートの「リソース」タブを選択します。

2. 一覧の各リソースをクリックし、スループットなどが、各クラウドベンダーの利用上限(レートリミットまたはクウォータ)を超えていないかを確認します。レートリミットまたはクウォータは、「種類」に記載された名前を使って、インターネットを検索してください。下の例では、スループットがAWS::CloudFrontのレートリミット250,000rpsを超えています。

3. 利用上限を超えたリソースについて、クラウドベンダーに上限の緩和申請を提出します。クラウドベンダーとの契約を管理するアカウント管理者に、申請を依頼してください。 なお、申請は必ず承認されるとは限りません。承認されなかった場合、複数のリソースに通信を分散させるなどの、設計の見直しが必要です。


ステップ2:外部システムの上限緩和申請

1. レポートの「アクター」タブを選択します。

2. ロボットのアイコンがついたアクターが、クラウドに連携する外部システムです。外部システムとの契約を管理する担当者に、利用上限(レートリミットまたはクウォータ)を確認しましょう。 確認ができたら「関連コンテキストを開く」ボタンをクリックし、次に進みます。

3. 選択されたコンテキストをクリックします。

4. 画面右の図面でロボットのアイコン(下図の「外部CRMシステム」)につながる線に、カーソルをあわせます。表示された「最大性能」等の通信ボリュームが、外部システムの利用上限を超えていないかを確認しましょう。

5. 利用上限を超えた外部システムについて、契約の担当者に上限の緩和申請を依頼します。 申請が承認されない場合、キューイングシステムで通信頻度を調整するなど、設計の見直しが必要です。


ステップ3:必要に応じた冗長化

1. レポートの「コンテキスト」タブを選択します。

2. コンテキストの一覧から、障害からの復旧スピードが求められるコンテキストを探してクリックします。 そうしたコンテキストの特定が難しい場合は、レポートの「アクター」タブから重要なアクター(カスタマーやクライアントなど)を選んで「関連コンテキストを選択」ボタンを押した後、選択されたコンテキストをクリックしてください。

4. 図中のアクターを起点とした矢印に沿って各リソースを順にクリックして、単一障害点を探します。下の例では「ロードバランサー」、「Webサーバ」、「DBサーバ」、「セキュリティ監査ログ処理」の順に見ていきます。「(副次的リソース)」と書かれたリソースにつながる薄灰色の矢印は主要な通信経路はないため、今回は無視します。

まずロードバランサーをクリックすると、本リソースの種類は「AWS::ElasticLoadBalancingV2::LoadBalancer」であるとわかります。同リソースは下枠の「マネージドサービス型のリソース」に該当するため、冗長化されています。次にWebサーバは「AWS::AutoScaling::AutoScalingGroup」なので「オートスケーリング型のリソース」に該当し、冗長化されています。
どのリソースが下枠のどのケースに相当するか不明な場合には、設計者に問合せてください。
そしてDBサーバですが、こちらは「AWS::RDS::DBInstance」なので冗長化されていない可能性があります。左の一覧から「ソースコードを確認」を押して、詳しく見ていきましょう。なお「ソースコードを確認」は当該リソースのキー名を含む箇所を順にローテーションするため、確認したいコードにたどり着くまで複数回クリックしてください。本例ではコード中に「"MultiAZ":true」の表記が確認できたものとして、下の「リソースのオプションで冗長化が設定されている」に該当し、冗長化されていると判断します。
最後に「セキュリティ監査ログ処理」はgcpTemplate.yaml内で定義されている、GCPの「compute.v1.instance」です。こちらは1台の仮想マシンとなるため、冗長化の必要性を検討すべきです。マネージドサービスに切り替えるか仮想マシンを2台に増やして冗長化する、あるいは「Webサーバ」自体に一定期間ログのオリジナルを残して問題発生時に復旧する運用により、ログ喪失リスクを低減して冗長化を不要とするか、といった判断が考えられます。

マネージドサービス型のリソースが選択されている場合、単一障害点ではない: 

・例えば下図のLoadBalancerは、サーバ台数を意識せずAWSに障害耐性を任せるマネージドサービス型のリソースです。同種のリソースは冗長化への配慮ができおり、単一障害点でないと判断できます。ただし当該サービス自体の障害リスクを甘受できない場合には、別種別のサービスを組み合わせた設計(例:CloudFrontの停止リスクが甘受できない場合、DNSフェールオーバー機能でAPIGatewayにフェールオーバーさせるなど)が必要です。 なおリソースがマネージドサービス型かどうかは、各クラウドベンダーのドキュメントをご確認ください。

オートスケーリング型のリソースが選択されている場合、単一障害点ではない: 

・例えば下図のAutoScalingGroupは、障害リスクが高まった時に自動的にサーバ台数が調整されるオートスケーリング型のリソースです。同種のリソースは冗長化が考慮されており、単一障害点ではないと判断できます。ただし設定によっては単一障害点になり得るため、確実な冗長化が必要な場合、フェールオーバーの詳細を設計者に確認してください。

リソースのオプションで冗長化が設定されている場合、単一障害点ではない: 

・複数のリソースが利用されていなくても、リソースのオプションによって冗長化されている場合があります。 例えば下図のDBInstanceには、サーバ障害時に待機サーバへと処理を自動的に切り替える、冗長化のオプション(Multi-AZ)があります。 オプションが有効になっているかどうかは、「ソースコードを確認」をクリックし、コードエディタでプロビジョニングコードを確認してください。 なおリソースに冗長化のオプションがあるかどうかは、各クラウドベンダーのドキュメントをご確認ください。

付録


ForkMe!とReindeer


ForkMe!はReindeerTechnologyPTE.LTD.の提供です。
Reindeerはクラウド活用の支援を通じ、すべての人々につくる力を届けたいと願っています。
誰もが自分の力でサービスを創造できる社会は、表現の自由と生活様式や価値観の多様性をもたらすだけではありません。それはまた、すべての人々に対
誰もが自分の力でサービスを創造できる社会は、表現の自由や価値観の多様性をもたらすだけではありません。それはまた、すべての人々に対する富の再分配を促進し、世界中の人々に平等な富と幸福をもたらすと信じています。 する富の再分配を促進し、世界中の人々の平均的な富と幸福を改善すると信じています。


ForkMe!

Reindeer Technology PTE. LTD.



商標

・アマゾン ウェブ サービス、Amazon Web Services、AWS、およびかかる資料で使用されるその他のAWS商標は、Amazon.com, Inc.またはその関連会社の商標です。
・Google、「 Google Cloud Platform (GCP) 」「 Google Cloud Platform (GCP) ロゴ 」は、 Google LLCの商標または登録商標です。
・Microsoft、Microsoft Azureは、米国Microsoft Corporationの、米国およびその他の国における登録商標または商標です。
・Terraformは、HashiCorpの登録商標または商標です。
・その他、記載されている会社名および商品・サービス名は各社の登録商標または商標です。