”セキュリティバイデザイン”を踏まえたAWSのセキュリティ要件の考え方ーNISC SBDマニュアルを参考にー

内閣官房 内閣サイバーセキュリティセンター(以下、NISC)は、2022年7月29日に「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル」（以下、SBDマニュアル）を改訂いたしました。

こうしたマニュアルは調達を担当される政府の各組織の皆様や、また調達に対して提案を行うサービス事業者様の双方にとってセキュリティ上の考慮事項の認識を深める上で有用なものとなります。また、”SBDマニュアルは政府機関等の職員向けに作成しておりますが、一般の企業においても御利用いただける内容”（NISCホームページより）とあるように、政府関係者だけではなく、多くの組織においてもセキュリティ設計のヒントとなる情報を提供しています。

本Blogでは、本SBDマニュアルを踏まえ要件定義からセキュリティ対策の設計段階でのAWSのセキュリティをご理解いただくための要点を提供いたします。

サービスのライフサイクル全体を見渡したセキュリティ

NISCでは「情報セキュリティを企画・設計段階から確保するための方策（SBD: Security By Design）」という考え方を踏まえ、NISCでは平成23年3月の初版発行から本SBDマニュアルの改訂を行ってきました。

こうしたセキュリティバイデザインの思想は、より上流の企画段階からセキュリティを考慮することで、対策に関わるコスト（金銭的なコストだけではなく、後付けで対策を行うことによる設計・運用の複雑性の増加や人的な対応も含む）の効率化を実現するために必須の考え方となります。

AWSにおいてはこうした思想を実践するものとして”設計の対象は、アクセス権限、ログ記録、信頼関係、暗号化の要求、承認されたマシンイメージの要求といった AWS のお客様の環境内にあるすべてのもの”とし、”SbD(注：AWSによる略称は小文字のbを使っています) により、お客様は、AWS アカウントのフロントエンド構造を自動化し、セキュリティやコンプライアンスを AWS アカウントに信頼性の高い方法でコーディングし、IT 統制すべてにコンプライアンスを適用することができる”としています。

「別冊．クラウド設計・開発編」の活用

本SBDマニュアルでは、システムの大きなライフサイクルのプロセスとして、要件定義、調達、設計、開発、運用保守・廃棄という流れを定義しており、特に本マニュアル自体は、要件定義および調達のプロセスにおけるセキュリティ要件の策定を対象としています。また、「別冊．クラウド設計・開発編」（以下、本別冊）では、設計、開発段階におけるセキュリティ設計の実装のために有益な情報を提供しています。システムのライフサイクルを見通したシステム管理の全体像を見越した全体設計を行うこと、さらには必要な対策を前工程であらかじめ組み込むことはセキュリティバイデザインの考え方を実践するものとなります。

特にクラウドを活用したシステムの特性に鑑み、設計・開発時のセキュリティ対策および運用・保守時のセキュリティ対策（廃棄を含む）には、オンプレミスとクラウドにおいて必要とされる要件が異なることがあることも示しています。

クラウドサービスの変化、進化を踏まえた設計の考え方

設計にセキュリティを組み込むこと自体は従来のIT環境でも考慮されてきたことかもしれません。ただし、従来の環境ではシステムは当初の設計から大きく変化していくことは想定されておらず、柔軟な拡張が困難なハードウェアリソースの制限などもあり、後付けのセキュリティ対策を組み込むことに困難が伴うこともありました。

クラウドの環境を考える上では、AWS上のお客様の環境もエンドユーザーのニーズを踏まえ動的に変化することが考えられます。予期しない設定ミスなどによりセキュリティインシデントの引き金となることも懸念されます。また一方で、AWSがお客様のニーズに踏まえ、様々な新機能やサービスのアップデートを行っています。AWS上の環境の変化をすばやく検知し、かつサービスアップデートの恩恵を適切に組み込むことで、システムのライフサイクルを通じたセキュアな環境を維持しアップデートすることが出来ます。”設計にセキュリティを組み込む”ということを踏まえる上ではこのようなクラウドの特性をどのように設計に組み込むことが出来るか、という視点が重要となります。

具体的には環境の動的な変化を踏まえ、発見統制を適切に組み込むこと、AWS自体の様々なアップデートを適用できるような変化に強いシステム設計を実装し、それを可能とする運用体制が必要となります。

CIS Benchmarkを活用したセキュリティ対策ベースラインの設計

本別冊では、米国の政府機関・企業等が協力して設立された非営利団体 CIS（Center for Internet Security）が発行しているセキュリティ対策のベストプラクティスである「CIS Benchmark」を活用した設計を紹介しています。こうしたベストプラクティスを発見的な統制としてあらかじめ組み込むことでセキュリティ設計上の抜け漏れや逸脱の検知を容易にする、”ガードレール”としての役割を果たすことが期待できます。

CIS BenchmarkはAWSを含めた主要なクラウドサービスやOS、ミドルウェアなどのセキュリティ対策のベースラインを網羅的に定義しているものであり、単なる対策のみではなく、その評価方法（実装の判定をするための具体的なコマンドなど）もあわせて紹介しています。また、CISがベンチマークをアップデートするため、組織側が細かい実装レベルに求められるセキュリティ対策を一から考え、更新する必要がありません。

ベースラインを適用するメリットと考慮事項

定義されたセキュリティ要件を実際の設計に落とし込むことは、従来であればその精査だけでも多くの工数がかかり、また手作業による見落としなども懸念されます。すでに広く受け入れられているベストプラクティスを柔軟に活用することでより要件定義に即した設計をすみやかに適用することができますし、組織はそのシステム固有のニーズに応じたセキュリティ設計に注力することができます。

一方、CIS Benchmarkをはじめとしたベースラインは汎用的に活用いただくための最低限の要求であり、個別の組織の事情やシステムのニーズを反映するものではありません。ベースラインとして定められているものに対して適用しない場合においても、またベースラインに定められていないものを追加の統制で必要とする場合も、いずれも組織として、達成すべきセキュリティの水準や要件を定義し、その実装を行うことが求められます。

AWS環境のベースラインの組み込み

また、AWSでは、AWS Security HubやAWS Configを活用してCIS Benchmarkをサービスの中に組み込み、お客様のセキュリティ状況を可視化、またはお客様側で検知された違反を自動的に修正するアクションを組み込むことが可能です。各ベンチマークに対する情報はAWS Security Hubユーザーガイドでも紹介されていますので、ご確認いただければ幸いです。お客様個別のセキュリティベースラインの設定を行う上では、AWS Configの発見的統制を実装するConfig Rulesにより、カスタムルールとしてお客様が自身のセキュリティ要件に固有のルールを作成し、実装することも可能です。

また、セキュリティバイデザインの考え方にのっとり、セキュリティ要件にもとづく設計をガードレールのようにすべての環境に一律に適用することができれば、”すでに要件の中でセキュリティの実装が考慮されている”という環境を用意に準備することができます。AWS Control towerでは、わずか数回のクリックで、マルチアカウントの AWS 環境のセットアップを自動化します。セットアップにはブループリントを使用し、これには AWS のセキュリティおよび管理サービスを設定するための AWS のベストプラクティスを収めています。

さらには私達のソリューションアーキテクトがオープンソースプロジェクトとして公開しているBaseline Environment on AWS（BLEA）は、テンプレート群として AWS のセキュリティサービスを活用して基本的かつ拡張可能なガードレールを提供します。

変化に強いシステム運用を実現するための組織管理

様々な情報システムは本来その利用者のニーズを充足するために存在するものであり、それは公共や民間を問わず変わるものではありません。セキュリティという観点で見れば設計時には想定されていなかったあらたな脆弱性が運用フェーズで発見され、その対応が必要になる、また、設計や開発当初にはなかった有効なセキュリティソリューションなどが登場し、環境に組み込むことでより確かにセキュリティ脅威に対応できることなどは、一つのシステムに対するニーズの充足という側面があります。

組織の仕組み、という観点からは本番環境をリリースした時点でそのシステムの変化を凍結するのではなく、定期的にそのシステムが求められているニーズを実現しているか、技術の進化などに応じたベストプラクティスを適用できているかを評価していく仕組みが必要となります。

AWSではWell Architected Frameworkにより、サービス設計の原則をお客様がレビューすることが可能な原則を提供しており、クラウドアーキテクトがさまざまなアプリケーションやワークロード向けに高い安全性、性能、障害耐性、効率性を備えたインフラストラクチャを構築する際に役立ちます。AWS Well-Architected では、6 つの柱 (優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性) に基づいて、お客様とパートナーがアーキテクチャを評価し、スケーラブルな設計を実装するための一貫したアプローチを提供しています。

このようなレビューを設計時の一過性のものととらえるのではなく、システムのライフサイクルを通じた見直しや評価の機会として組み込むこと、運用のプロセス自体もシステム設計の前工程において想定しておくことができれば、よりセキュアな環境の維持につながります。

まとめとして：クラウドの価値をセキュリティ上でも適用することの価値

本Blogでは、NISC SBDマニュアルの紹介を踏まえ、AWS上でセキュリティバイデザインをどのよう設計していくかのヒントを提供いたしました。AWSを使うということはクラウドの価値を活かしたサービス設計がニーズに合致することが求められているからに他なりません。セキュリティ設計においてもAWSを活用することでもたらされる価値は何か、それがシステムのライフサイクルを通じて恩恵を受けられるよう、より要件定義や設計の早い段階から全体を通じて構想されることをお勧めします。

このブログの著者
松本　照吾（Matsumoto, Shogo）
セキュリティ アシュアランス本部 本部長