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

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


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

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


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

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

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

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

判断基準の例

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

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

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


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

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

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

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


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

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

2. 一覧に表示されるすべてのコンテキストをひとつずつクリックし、詳細をチェックします。

3. 画面右下の図で、白枠のボックス同士を結ぶ線が通信経路です。図に含まれるすべての通信経路について、以下を参考に安全性をチェックしてください。もし危険、または注意すべき通信が含まれる場合には、その必要性を設計者に確認します。そして可能な限り最小限の利用にとどめるよう、設計者を指導してください。

危険な通信: インターネット通信(赤塗の線) + 無制限通信(鍵のあいた赤のアイコン) + 個人情報/機密情報を含む情報種別(下例の「クラスA」の部分)

・この種の通信は、セキュリティリスクが高く危険な状態です。不特定多数向けの会員サイト表示等でやむなく必要になりますが、可能な限り最小限の利用にとどめるよう、その必要性を慎重にチェックしてください。
※注意:ポートが22/443/465/995以外の場合、通信を暗号化するよう設計者に依頼してください。

注意すべき通信: インターネット通信(赤塗の線) + 制限通信(鍵の閉じた緑のアイコン) + 個人情報/機密情報を含む情報種別(下例の「クラスA」の部分)

・この種類の通信は、制限が不十分でセキュリティのリスクが低減できていない可能性があります。よって可能な限り最小限の利用にとどめるよう、その必要性、制限の方式を慎重にチェックしてください。
※注意:ポートが22/443/465/995以外の場合、通信を暗号化するよう設計者に依頼してください。

シーン2:コストの評価

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


ポイント:費用対効果

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


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

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

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


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

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

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

3. 画面右に表示されるアクター、リソース、コンテキストの関連図で、コンテキスト(関連図中央の列)とリソース(関連図右端の列)の関連性(両列の結線)に注目します。右列のリソースのうち、1本しか線が繋がっていないものは、1つの用途で占有されるリソースです。占有リソースを見つけたら、次に進みます。(下の例では、AdministrationInstanceなど)

4.  占有リソースに繋がる線にカーソルをあわせ、リソースを占有するコンテキスト名(下の例では「システム管理」)を確認します。この名称を見て明らかに重要性が高いと判断できた場合、占有の妥当性が高いため、次に進む必要はありません。重要性が低い/わからない場合には、次に進みます。

5. 占有リソースに繋がる線をクリックすると、下図のように対象リソースが選択されます。他リソースへの処理の相乗り等で同リソースを削減できないか、設計者に検討を依頼してください。
注意:選択されたリソースの概算コスト(下の例では2,228円/月)は、ForkMe!が計算できる範囲での概算コストです。占有リソースの排除は、より大きなコスト削減になる可能性があります。

6. なお、下図のようにコンテキストとリソースの結線が大量にある設計では、類似の用途が複数のコンテキストに細分化されている場合があります。よって共有リソースを特定する際は、コンテキストとの結線が1本のリソースだけではなく、結線の数が他リソースより相対的に少ない(数本の)リソースも対象としてください。

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

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


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

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


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

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

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

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


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

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

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

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

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

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


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

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

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

3. 画面右に表示されるアクター、リソース、コンテキストの関連図を使って、障害からの復旧スピードが求められるコンテキストを探します。重要なアクターにつながるコンテキストが対象になる可能性が高いため、特にアクター(図の左端列)とコンテキスト(図の中央列)の関連に注目します。下の例では、「サイト訪問者」につながる「サイト閲覧」が対象になりそうです。

4. システム俯瞰図の対象コンテキストをクリックすると、画面右の図がコンテキストごとのデータの流れに変わります。図中の各リソースを順にクリックし、詳細を見ていきましょう。下の例では、「02 ロードバランサー」をクリックします。

5.  画面左のレポートで、クリックしたリソースが選択表示されます。以下の指標を参考に、単一障害点を探してください。 単一障害点とは単一リソースの問題がシステム全体に影響を及ぼす箇所で、解消にはリソースの冗長化が必要です。

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

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

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

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

同種のリソースが複数選択されている場合、単一障害点ではない: 

・例えば下図ではAWS:EC2:Instance(AWSのEC2サーバ)が2台選択されているため、単一障害点ではないと判断できます。ただし、これらの目的が負荷分散で障害時の考慮がなされていない場合、冗長化が不十分な可能性があります。確実な対応を求める場合には、フェールオーバー動作の詳細を設計者に確認してください。

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

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

6.  単一障害点を発見した場合、設計者に冗長化の検討を依頼しましょう。 ただし、一般的に冗長化には追加のコストがかかるため、実施の要否は必要性に応じて判断すべきです。 本ステップの2.で障害からの復旧スピードに着目した通り、復旧スピードが要求されない用途、あるいは運用担当者の手作業によって必要な復旧速度が確保できる場合には、冗長化の必要はありません。

付録


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の登録商標または商標です。
・その他、記載されている会社名および商品・サービス名は各社の登録商標または商標です。