はじめに
この記事は、Supershipグループ Advent Calendar 2021の24日目の記事になります。
組織がスケールするにあたり、アジリティを下げずにセキュリティを高めていくためには、正しいクラウド戦略が必要です。
本記事はクラウドインフラ（AWS）でセキュリティを実現するための考え方や、マルチアカウントの運用方法について記載しています。
前半はCloud Center of Excellence（以下、CCoE）の観点から、セキュリティ・ガバナンスを実現するために、フレームワークの考え方や、ガードレールなどクラウドにおけるセキュリティ対策の考え方について記載していきます。
後半はセキュリティ・ガバナンスの実装方法として、AWS Control Towerを軸に、関連するAWSサービスの概要やポイントについて解説しています。
※CCoEについては以前書いたCloud Center of Excellenceとは何かを参照。
※本記事の内容は、あくまで考え方の一例であり、必ずしも全ての考え方がシステムに適合したり、ここに書いている内容で満たされている訳ではありません。
クラウドセキュリティの考え方
今後もDX促進によりビジネスでクラウドを活用した動きは、これからも加速してくるでしょう。
背景として、2021年度（令和3年度）税制改正に伴い、DX投資促進税制という制度が新設されました。国として企業のクラウドシステム活用を支援しています。
こうした中、先日、田舎の病院がサイバー攻撃を受けたことが発覚し、ニュースになりました。
クラウドシステムにおけるセキュリティの考え方は、従来のオンプレミスのシステムにおけるセキュリティの考え方とは異なります。
責任共有モデルを理解し、利用者側の責任範囲を明確にすることで、セキュリティ対策の意味が問われます。
課題解決は、目的と手段を混合しないことが重要です。
今のクラウドはセキュリティをはじめ、色々なサービスが存在しますが、サービスやツールを使用することを目的にしてはいけません。
何故セキュリティ対策をやるのか？
どこまでセキュリティ対策をやるのか？
誰のためにセキュリティ対策をやるのか？
何を根拠にセキュリティ対策を保証するのか？
本質的に考え抜くために、セキュリティ対策について深掘りしていきましょう。
フレームワーク
従来、オンプレミスのシステムでインフラ基盤の新規構築を行う場合、非機能要求グレードを利用して要件定義を行うことが多かったのではないでしょうか。
オンプレミスでミッションクリティカルなシステムを構築する場合、非機能要求グレードを基に、ベースモデルを選定し、以下の各項目を定義していきます。セキュリティについても、機能要求グレードの中で要件を定義し、定義した要件を基にセキュリティ設計を行います。
- 可用性
- 性能・拡張性
- 運用・保守性
- 移行性
- セキュリテイ
- システム環境・エコロジー
現在は非機能要求グレード2018が最新版となっています。
しかし、クラウドファーストの今、非機能要求グレードを用いてクラウドシステムの要件定義を行うのは、難しいと思います。理由として、非機能要求グレードがオンプレミスの観点で書いてある内容が多いため、クラウドやコンテナを活用している今時のシステムには向いてないからです。
では、クラウドシステムのセキュリティについて考える場合、何を基に手掛けるのが最善でしょうか？
そこで登場するのがNIST Cyber Security Framework（以下、CSF）などのフレームワークになります。
なお、日本では総務省が情報セキュリティ対策の指針として、以下のガイドラインを公開しています。
NIST Cyber Security Framework（CSF）
CSFは米国国立標準技術研究所（NIST）が公開している、サイバーセキュリティフレームワークです。
大統領令を受けて、NISTが政府や民間から意見を集めて作成したベストプラクティスになります。
米国の政府機関に関わるシステムや、重要インフラなどはCSFの採用が義務付けられているため、如何にCSFの正当性が分ります。
なお、CSFは重要インフラでの採用を意図したものではありますが、業界や規模を問わず、あらゆる組織の規範とされています。
AWS クラウドセキュリティはCSFを基に設計されています。
CSFは以下の構成となっています。
- コア（セキュリティ対策の分類）
- 識別
- 防御
- 検知
- 対応
- 復旧
- ティア（セキュリティ対策に対する、組織の成熟度を4段階で数値化）
- プロファイル（As Is/To Be）
コアは重要インフラの分野に共通となるセキュリティ対策、期待されるや効果、参考情報をまとめたものになります。また、5つの機能で構成されています。
ティアはリスク情報を活用したアプローチがどこまで達成されているかなど、組織の成熟度を評価します。
プロファイルは現在のプロファイル（今の状態）と、目標のプロファイル（目指す状態）を比較し、ギャップを見極めます。また、リスクアセスメントを行なって必要なリスクを決定し、優先度付けなどを行います。なお、プロファイルについてはフォーマットは決まっていません。
AWSの米国国立標準技術研究所 (NIST)から、CSFを基にAWS仕様でカスタマイズされたマトリクスのドキュメント（xlsx）がダウンロードできます。
上記、ダウンロード可能なCSFのマトリクスは英語になっています。シンプルにCSFの日本語版が欲しい場合は、以下に示すIPAのIPAのセキュリティ関連NIST文書からダウンロードできます。
導入するシステムの要件によっては、全てを満たす必要がなく、適合しない場合があると思います。この様なフレームワークを使用する際は、組織やシステムの規模に合わせて、必要な項目のみ使用するなどフレキシブルに適用する方法が良いでしょう。
CSFを基に本記事で解説するAWSの関連サービスが以下になります。
ガードレールの考え方
ここ数年、セキュリティ業界ではゼロトラストセキュリティという考え方が浸透しつつあります。
従来の保護すべきデータは社内に存在し、社外からはアクセスできないなど境界線で考えるセキュリティ対策ではなく、全ての通信やデバイスを信用せずに検証することで、脅威を防ぐというセキュリティモデルです。
注意すべき点として、ゼロトラストセキュリティはフレームワークではありません。そのため、共通言語が不足しています。現在の状況としては、SP 800-207として文書化されています。日本ではPwCコンサルティング合同会社が翻訳・公開しています。興味ある方は以下をご参照ください。
合わせて、AWSが提唱するガードレールの考え方も重要です。
従来のゲート型と、ガードレール型のイメージは以下になります。
-
ゲート型
- 境界線を定義し、ルールベースでセキュリティを実現するための考え方
-
ガードレール型
- 禁止操作の制限及び、危険な設定を検出してセキュリティ・ガバナンスを実現するための考え方
ガードレールは開発者に自由を与えつつ、絶対に超えてはいけない領域を制限することで、セキュリティ・ガバナンスをコントロールします。
ビジネスモデルに応じたクラウドセキュリティ
現実は理想に対して、複雑です。
ビジネスモデルにより、システム開発やクラウドを使用する状況は異なります。
- 新規構築/リプレイス/システム移行
- 一つのサービスやプロダクト
- 共通基盤
- 基幹系システムなど大規模なサービス
- 複数ドメイン
- 会社の中で複数の事業を展開し、事業毎に別々のクラウドが混在する環境
クラウドを安全に利用するために、ビジネスモデル、組織の規模、カルチャー等を踏まえて、汎用的に補完できるセキュリティの考え方は存在するのでしょうか？
私は、セキュリティの原理原則に従い、フレームワークの適用及び、ガードレールを整備し維持し続けることが、最善ではないかと考えています。
また、サイバーハイジーンの考え方に従ってエンドポイントの脆弱性を排除、可視化、すなわち日々の運用がセキュリティを作ります。そして、時代に合わせてゼロトラストセキュリティなど新しい考え方を適用し改善し続けていくのが理想だと思います。
マルチアカウント運用
組織が事業活動を行うために、内部統制の仕組みが必要な様に、クラウドを効率かつ効果的に利用するために、マルチアカウント運用は必要不可欠な仕組みです。
マルチアカウント運用のベネフィットは以下になります。
- 環境の分離
- 開発/ステージング/本番環境等を分離し、セキュアな運用を実現
- 請求の分離
- サービス/システム単位で分離し、コスト管理の利便性が向上
- 権限の委譲
- コーポレートなど経理の方が、スタンドアロンで請求確認が可能（管理者の運用負荷低減）
- リスク分散
- 局所的な影響を減らし、インシデント発生時のリスクを低減
- ボリュームディスカウントの共有
- 組織内のメンバーアカウントの使用料を全結合し、ボリュームディスカウント（従量制割引）や、リザーブドインスタンスの共有が可能
ソリューション
AWS環境でマルチアカウント運用を実現するための手段として、かつてはAWS Organizationsを軸に実施されていたと思いますが、現在脚光を浴びているのがAWS Control Towerです。
AWS Organizationsなど関連するサービスがラップした構成になっているため、初見の場合分かりにくいですが、一つずつサービスを理解することで、AWS Control Towerを使うべき理由が理解できます。
また、組織全体のセキュリティを可視化するための統合ツールがAWS Security Hubです。
AWSではこの二つの補完的なサービスを利用することで、セキュリティ・ガバナンスを実現することができます。
以降、セキュリティ・ガバナンスを実現するために必要となる、関連するAWSサービスについて記載しています。
認証・認可の仕組みとして、AWS Identity and Access Management (IAM)や、SSOを実現するAWS Single Sign-Onも欠かせませんが、本記事では割愛します。
AWS Control Tower
AWS Control Towerは、マルチアカウント環境を実装するための手段です。
セットアップを開始すると、マルチアカウント環境の運用を実現するために、AWS Organizationsを自動的に設定し、ガードレールを実装します。
サービス自体は2019年から存在していましたが、リリース当初は東京リージョンが利用できませんでした。
そして、来るべき2021年4月から東京リージョンでも利用出来る様になりました。
AWS Control Towerの特徴は以下になります。
- ベストプラクティスを基に、Landing Zoneを設定
- ガードレールを適用し、ポリシー違反につながるアクションを禁止、または、ポリシー違反などアカウント内のリソースの非準拠を検出
- ガードレールの適用状況をダッシュボードで可視化し、一元的な管理が可能
- Account Factoryで新規アカウントのプロビジョニングを標準化
AWS Control Towerが提供するガードレールは、AWSが民間と一緒に作りあげたセキュリティ対策のベストプラクティスになります。セキュリティで重要と思われる項目が選定されています。
ガードレールは予防と、検出の2種類が存在します。
予防のガードレールは強制的に該当操作をできない様に、Organizationsのサービスコントロールポリシーで設定されます。
検出のガードレールは該当操作を検出するために、Config Rulesで設定されます。
ガードレールを使用することにより、ポリシーの意図を表現できます。
また、2021年11月末のアップデートではリージョン毎の制御も出来る様になりました。
AWS Control Towerを使用することで、以下の様に用途に応じて柔軟なセキュリティ・ガバナンスを実現できます。例えば、ガードレールの予防ルールで海外リュージョンを禁止することで、知らない間に海外にデータが存在しているなど、リスクとなり得る行為を予防することができます。
AWS Control Towerを利用する際のガードレールの見方や、操作方法について以下に記載します。
- 現在、OUにどのガードレールが適用さているかは、AWS Control Towerの組織単位ペインから、「有効なガードレール」を参照。
- OUに対して、ガードレールの設定変更を行いたい場合、AWS Control Towerのガードレールペインから、変更したいガードレールを選択し、有効にする場合は「組織単位が有効」から「OU でガードレールを有効にする」を選択。無効にしたい場合は、「ガードレールを無効にする」を選択。
- ガードレールの設定を変更する際に、複数のOUを一括に選択する操作はできない。
- 新しいガードレールは適宜追加されるため、AWS Control Towerのガードレールペインからリリース日を参照。
- AWS Control Towerセットアップ完了後、すべての必須のガードレールがデフォルトで有効になる。なお、必須のガードレールについて個別で変更はできないため、ガードレールを適用したくない場合は、OUから移動する必要がある。
AWS Landing Zone
AWS Control Towerを理解するために、最初に理解した方がいいと思うのが、AWS Landing Zoneです。
AWS Landing Zoneについて検索すると、抽象的な説明が多く理解がしにくいと思います。
以下はAWS Landing Zoneについて、ユーザーガイドの説明です。まずはこの様な考え方があることを、抑えておけば良いかと思います。
ランディングゾーン— landing zone は、よく設計されています,複数アカウント環境は、セキュリティとコンプライアンスのベストプラクティスに基づいています。これは、すべての組織単位 (OU)、アカウント、ユーザー、およびコンプライアンス規制の対象とするその他のリソースを保持するエンタープライズ全体のコンテナです。ランディングゾーンは、いずれの規模の企業のニーズに合わせてもスケーリングできます。
なお、AWS Landing Zone ソリューションは現在、長期サポート中で別物になります。
AWS Organizations
AWS Organizationsは、複数のAWSアカウントを統合するためのアカウント管理サービスです。
AWS Control Towerセットアップ時に合わせて有効になります。
ガバナンスを目的とし、AWS Organizationsの機能を手段とすることで、マルチアカウントの課題を解決します。
例えば、全AWSアカウントの利用料を管理アカウントへ統合し、一括請求を行なったり、クレジットカードの情報を必要とせずにAWSアカウントの作成を行うことができます。
AWS Control Towerを活用するためには、以下の概念を理解しておくと良いでしょう。
OUについてもっと知りたい場合は、AWS ホワイトペーパーの「Organizing Your AWS Environment Using Multiple Accounts」のRecommended OUsを参照。
AWS Control Towerを利用する際のOU設計で考慮すべき点について以下に記載します。
- AWSの推奨するOUは必ずしも全てを満たす必要はない。環境に合わせて独自のOU構造を定義することが望ましい。
- 2021年11月のControl Towerのアップデートで、ネストされたOUがサポート。いくつか留意事項があるため、詳細はユーザーガイドのNested OUs in AWS Control Towerを参照。（ネストされたOUで、検出は継承されなく、防止は継承されるのが特徴）
- AWS Control TowerからOUを作成すると、AWS OrganizationsにもOUは反映される。逆にAWS OrganizationsからOUを作成すると、AWS Control Towerにも反映されるが、OU未登録の状態になる。つまり、ガードレールも適用されていない状態になる。
- AWS Control TowerからOUを移動することは現状、不可能な操作となっている。そのため、OUを移動させたい場合は、AWS Organizationsから移動する。OU移動後、AWS Control Towerの組織単位ペインを見ると、「管理対象のアカウント」の表示が0/1となるため、OUを再登録する作業が必要。
AWS CloudTrail
AWS CloudTrailは、ユーザー、ロール、または AWS のサービスによって実行されたアクションをイベント履歴として記録します。イベント履歴には、AWS Management Console、AWS Command Line Interface、および AWS SDK と API で実行されたアクションが含まれます。
「いつ」、「だれが」、「何を」したのかが記録されるため、不正アクセスなどを確認することを目的に監査ログとして扱うことができます。
AWS CloudTrailの特徴は以下になります。
- CloudTrailは、作成時にAWSアカウントで有効になっているが、全てのアクションをサポートしている訳ではない
- ログはS3に保存され、KMS キーを活用してCloudTrailログをさらに保護することが可能
- CloudTrailのイベント履歴
- 管理イベント（AWSアカウントのリソースで実行される管理操作に関する情報）
- データイベント（リソース上またはリソース内で実行されるリソース操作に関する情報）
- Insightsイベント（AWSアカウントの異常なAPIコールレートまたはエラーレートアクティビティ）
- CloudTrailのイベントログは、過去90日間のイベントの表示、検索、およびダウンロード可能（証跡を作成することで、S3に90日以上のイベントログを保存することが可能になる）
- AWS Control Towerを使用している場合、Landing Zoneによって、Log archiveアカウントのS3に、アカウント毎のCloudTrailとConfigのログが集約される
AWS Security Hub
AWS AWS Security Hubは、セキュリティのベストプラクティスのチェックを行い、アラートを集約し、自動修復を可能にするクラウドセキュリティ体制管理サービスです。
セキュリティチェックは、AWS Configが記録した設定項目を利用します。
AWS Security Hubの特徴は以下になります。
- CISやPCI DSSなど業界標準となるベストプラクティスを利用し、セキュリティチェックを自動化
- 複数アカウントのチェックした結果を集約
- Amazon CloudWatch Events、AWS System Manager Automation、AWS Step Functions、AWS Lambdaなどと連携し、チェックした対応の一部について自動化（※）を実現
CIS（Center for Internet Security）は米国の独立した非営利団体の略称です。
なお、CISの提供している、CIS Controlsはフレームワークの一つで、AWSのSecurity Hubで利用される、CIS Benchmarkとは異なります。
※CIS AWS Foundations Benchmarkでは、自動的にチェックできない項目が存在します。
マスターアカウントのAWS Security Hubの画面にて、メンバーアカウントから集約したアラートを可視化できますが、検出結果をAWS CLIのコマンドで使用する際のナレッジを1点紹介します。
検出結果の詳細はget-findingsコマンドで取得できます。デフォルトではRecordStateがARCHIVEDのレコードも含まれるため、レコードが蓄積されているアカウントに対して実行すると、凄い時間がかかるため、フィルタリングして取得するのがお勧めです。
- AwsAccountIdを軸に、ComplianceStatusがFAILED、RecordStateがACTIVE、SeverityLabelを昇順でソートする例
$ aws securityhub get-findings --filters '{"AwsAccountId": [{"Value": "<account id>", "Comparison": "PREFIX"}], "ComplianceStatus": [{"Value": "FAILED", "Comparison": "EQUALS"}], "RecordState": [{"Value": "ACTIVE", "Comparison": "EQUALS"}]}' --sort-criteria '{"Field": "SeverityLabel", "SortOrder": "asc"}'
例えば、検出結果を分析するために大量のアカウントに対して、1アカウント毎にGUIで分析するのは現実的ではありません。AWS CLIなどを活用すれば、複雑な作業を簡単にこなすことができます。
AWS Config
AWS Configは、AWS リソースの設定を評価、監査、審査できるサービスです。
ガバナンスとしてガイドラインに違反していないかを検出するために、AWS Configを使用することで、AWSリソースの設定変更を継続的にモニタリングして記録します。
AWS Configの特徴は以下になります。
- AWSリソースを継続的に評価し、コンプライアンス違反やリソースの変化（作成、変更、削除）を検出
- 検出したイベントに対して、Amazon SNSを用いてEメール通知などが可能
- AWSリソースの設定及び、変更履歴を管理し、セキュリティグループの設定変更などトラブル発生時に変更を戻すことで修復可能
- 記録対象のスナップショットを取得することが可能
Amazon GuardDuty
Amazon GuardDutyは、AWSアカウントならびにAWS環境を継続的にモニタリングし、脆弱性となり得るアクティビティを検出するサービスです。
Amazon GuardDutyの特徴は以下になります。
- AWSコンソール上で有効化のボタンを押下するだけで、Amazon GuardDutyが開始される
- 内部的には機械学習 (ML)などの技術を使用し、ログから脅威を検出する仕組み
- Security Hubと統合して、Amazon GuardDutyの調査結果をSecurity Hubに送信
- Security Hubの検出結果の画面から、マルチアカウントの検出結果を集約
おわりに
これまではレガシーシステムや、統制がない環境でIaaS系のサービスを使用するなどしてクラウドを利用する立場でしたが、CCoEとして組織の中で推進する立場からクラウドを利用することは、新しい気づきや学びがありました。
日進月歩、テクノロジーの進化には驚きますが、されど利用する先には人間がいるので、本質的に考え抜き、クラウドを活用することが改めて重要だなと思いました。
ポストコロナと言われている今、現在、日本のDX市場で伸びているのは、情報通信業や、amazonなどの小売業です。
従って、まだまだ他の産業でのDXは始まったばかりなので、ブルー・オーシャンはまだあると思います。
クラウドを安全に利用し、ビジネスに活用するためには、まだまだエンジニアとして学び続けられる環境があるということではないでしょうか。
参考
DX
AWS ホワイトペーパー
ユーザーガイド
- AWS Control Tower とは
- AWS Organizations とは
- AWS CloudTrail とは
- AWSSecurity Hub とは
- AWS Config とは
- Amazon GuardDuty とは
AWS サービス別資料
最後に宣伝
Supershipではプロダクト開発やサービス開発に関わる人を絶賛募集しております。
ご興味がある方は以下リンクよりご確認ください。
是非ともよろしくお願いします。