本記事の目的/背景と対象スコープ
この記事には2つの目的があります。
まず1つ目にAWS Well-Architeted Frameworkと非機能要求グレードのリンク付けを行うことにより、従来のシステム構築のやり方に慣れている人たちがAWS Well-Architected Frameworkを有効活用できるようにすることです。
AWS上でシステム構築を行う際にAWS Well-Architected Frameworkを活用することは品質の高いシステムを作る非常に有効な方法ということはよく知られています。
また、日本のシステム構築では情報処理推進機構が作成・展開している非機能要求グレード2018が要件整理の段階で利用されるケースが非常に多く、特にSI案件のRFP等に別紙などに非機能要求グレードに従った整理結果が使われることがよく見受けられます。
これはユーザ企業の各御担当の方が過去の経験からそうしているケースもありますし、ユーザ企業の標準ルールとして非機能要求グレードを用いて整理することとしているケースもあるかと思います。
そのため、非機能要求グレードとAWS Well-Architected Frameworkという2つのツールをうまく結びつけて考えることができれば、ユーザ企業のようなシステム構築を依頼する側も、システム構築を実施に行う企業もAWSの使い方を正しく理解して案件を成功させられるのではないかと考えています。
それから2つ目に非機能要求グレードの項目ベースで具体的にAWSのどのサービスを活用しうるのか整理することで具体的なAWS環境の設計に即時役立てられるようにすることです。
この記事では特にセキュリティにフォーカスして記載をしますが、AWSのセキュリティサービスは数多く存在することと、ただサービスを導入するだけでなくそれらを適切に設計・運用していかないと十分な効果を得られないことが多くありますのでそれらの観点もまとめて記載することによりAWS上でシステムを安全に使うための手助けになるようにと考えています。
続いてこの記事のスコープについて非機能要求グレードの活用シートの中の大項目「セキュリティ」（項番E1.1.1～E11.1.1）をスコープとして、非機能要求グレードの小項目単位でAWSサービスを用いて実現できる要件について具体的にどのAWSサービスをどう活用するかを記載するとともに、AWS Well-Architected Frameworkのセキュリティの柱の内容とどう関連するのかを示していきます。
AWS Well-Architected Framework と 非機能要求グレード
AWS Well-Architected Framework については以下を参照ください。
非機能要求グレードについては以下を参照ください。
今回想定する構成
非機能要求に対してAWSサービスの活用方法を整理するにあたりサンプルとなるシステム構成を以下のように定義致します。
システム構成は典型的なWebシステムのもので、API通信でAmazon API Gateway - NLB - ECSタスク(AWS Fargate) - Amazon Aurora、画面通信でALB - ECSタスク(AWS Fargate) - Amazon Auroraを利用する構成です。
各種AWSのセキュリティ系サービスを活用し、コンテナのデプロイについてはCode系のサービスを使ってCICDを実施することとしています。
非機能要求グレード（セキュリティ部分）とAWS Well-Architected Frameworkの紐づけ
非機能要求グレードのセキュリティに関する項目とAWS Well-Architected Frameworkのセキュリティの柱の中の項目のリンク付けを行った結果が以下の通りです。
| 非機能要求グレードNo | AWS Well-Architected Framework |
|---|---|
| E.2.1.1 | SEC 7. どのようにデータを分類していますか? |
| E.3.1.1 | SEC 11. 設計、開発、デプロイのライフサイクル全体を通じて、アプリケーションのセキュリティ特性をどのように組み込み、検証すればよいのでしょうか? |
| E.3.1.2 | SEC 11. 設計、開発、デプロイのライフサイクル全体を通じて、アプリケーションのセキュリティ特性をどのように組み込み、検証すればよいのでしょうか? |
| E.3.1.3 | SEC 11. 設計、開発、デプロイのライフサイクル全体を通じて、アプリケーションのセキュリティ特性をどのように組み込み、検証すればよいのでしょうか? |
| E.4.1.1 | SEC 1. ワークロードを安全に運用するには、どうすればよいですか? |
| E.5.1.1 | SEC01 ワークロードを安全に運用するにはどうすればよいですか？ SEC02 ユーザーIDとマシンIDはどのように管理したらよいでしょうか？ SEC03 人とマシンのアクセス許可はどのように管理すればよいでしょうか？ |
| E.5.2.1 | SEC02 ユーザーIDとマシンIDはどのように管理したらよいでしょうか？ SEC03 人とマシンのアクセス許可はどのように管理すればよいでしょうか？ |
| E.6.1.1 | SEC 9. 転送時のデータをどのように保護していますか? |
| E.6.1.2 | SEC 8. 保管時のデータをどのように保護していますか? |
| E.6.1.3 | SEC 8. 保管時のデータをどのように保護していますか? SEC 9. 転送時のデータをどのように保護していますか? |
| E.7.1.1 | SEC04 セキュリティイベントをどのように検出し、調査していますか？ |
| E.7.1.3 | SEC04 セキュリティイベントをどのように検出し、調査していますか？ |
| E.7.1.4 | SEC04 セキュリティイベントをどのように検出し、調査していますか？ |
| E.8.1.1 | SEC05 ネットワークリソースをどのように保護しますか？ SEC06 コンピューティングリソースをどのように保護していますか？ |
| E.8.2.1 | SEC05 ネットワークリソースをどのように保護しますか？ |
| E.8.3.1 | SEC05 ネットワークリソースをどのように保護しますか？ |
| E.9.1.1 | SEC06 コンピューティングリソースをどのように保護していますか？ |
| E.9.1.2 | SEC06 コンピューティングリソースをどのように保護していますか？ |
| E.9.1.3 | SEC06 コンピューティングリソースをどのように保護していますか？ |
| E.10.1.1 | SEC 11. 設計、開発、デプロイのライフサイクル全体を通じて、アプリケーションのセキュリティ特性をどのように組み込み、検証すればよいのでしょうか? |
| E.11.1.1 | SEC 10. インシデントの予測、対応、復旧はどのように行いますか? |
非機能要求グレードのセキュリティに関する項目は37項目あり、そのうち半分以上の21項目についてAWS Well-Architected Frameworkで記載されている内容と関連があります。このことからもAWS上でシステムを構築するにあたっては非機能要求グレードを単体で利用するのではなく、AWS Well-Architected Frameworkも併せて活用することで効率的に品質の良いシステムの設計・構築が可能になるとわかります。
以下いくつかのポイントについて具体的に解説をしていきます。
E5.2.1 利用制限
非機能要求グレードの小項目説明：
認証された主体（利用者や機器など）に対して、資産の利用等を、ソフトウェアやハードウェアにより制限するか確認するための項目。
例） ドアや保管庫の施錠、USBやCD-RWやキーボードなどの入出力デバイスの制限、コマンド実行制限など。
AWS Well-Arthiceted Framework：
SEC02 ユーザーIDとマシンIDはどのように管理したらよいでしょうか？
SEC03 人とマシンのアクセス許可はどのように管理すればよいでしょうか？
解説：
非機能要求グレードでは物理的な内容からOSレイヤまでの内容をメインで説明が記載されています。
その一方でAWSにおいてはIAMを中心とするIDでの制御がメインとなります。特にユーザーIDとマシンIDと記載があるように、例えばシステム開発者がAWSのマネジメントコンソールを利用するためのIAMUser（ユーザーID）やEC2やECS等のAWSリソースが他のAWSリソースを操作するためのIAMRole（マシンID）等があります。
非機能要求グレードだけを利用している場合、特に後者のマシンIDの概念が考慮から漏れてしまい構築の段階で急遽AWSリソースに付与する権限を検討して、その結果権限が不足してテストで不具合が多発したり、過剰な権限を付与してセキュリティ上のリスクとなるケースがあります。
特にシステムの発注者側（主にユーザ企業様）が非機能要求グレードを使って整理した場合、権限の制御というとアプリケーション内部の権限を想定して記載されるケースもありますので、AWSのレイヤでどうなのかというところはAWS Well-Architected Frameworkを活用して整理することが必要です。
E11.1.1 セキュリティインシデント対応/復旧
非機能要求グレードの小項目説明：
セキュリティインシデントが発生した時に、早期発見し、被害の最小化、復旧の支援等をするための体制について確認する項目。
AWS Well-Arthiceted Framework：
SEC 10. インシデントの予測、対応、復旧はどのように行いますか?
解説：
非機能要求グレードでこの項目の備考として記載されている内容はインシデント対応マニュアルの整備やセキュリティ教育、CSIRT及び外部セキュリティ対応サービスの活用等が挙げられています。
これに対してAWS Well-Architected Frameworkではさらに踏み込んでセキュリティインシデント対応プレイブックの作成・テストやインシデント対応のシミュレーション、インシデント対応のためのツールの事前デプロイといった内容まで記述があります。
もちろんこれら全てをやらなければならないということではないですが、こういった内容をPJの初期段階で検討して要否を選択、必要と判断したものについて具体的にどう実現するか方針を定めておくことでセキュリティ対策を抜け漏れなく行うことに繋がります。特にセキュリティインシデント等いざというときに必要なツールはどこまで事前に準備しどこまでテストするのか（そもそもどこまでテストできるのか）の考え方が人や立場によりずれやすいポイントだと思いますので、これらをPJの初期段階で整理しておくことはPJのステークホルダー全員にとって有用なことであると考えます。
また、AWS Well-Architected Frameworkの中に含まれていて非機能要求グレードのセキュリティの項目の中ではあまり出てこないキーワードとして”自動化”というものがあります。
AWS Well-Architected Frameworkの中では以下のようにセキュリティの柱の中で頻繁に自動化という言葉が出てきます。
SEC.1
パイプラインのセキュリティコントロールのテストと検証を自動化するSEC.4
イベントへの応答を自動化するSEc.5
ネットワーク保護を自動化するSEC6.
コンピューティング保護を自動化するSEC.7
識別および分類を自動化するSEC.8
保管中のデータの保護を自動化するSEC.9
意図しないデータアクセスの検出を自動化するSEC.11
開発およびリリースライフサイクル全体を通じてテストを自動化する
この点について、AWSではマネージドサービスを利用することで自動化を実現することができる他、AWSのサービスを組み合わせて自動化の仕組みを開発することも可能です。自動化することで保守運用作業の負荷を減らしながら高いセキュリティ品質を実現することができますので、そういった意味でも要件定義・設計の段階で上記各自動化ポイントについて実現可否やその方法を検討しておくことが重要と言えます。
非機能要求グレード（セキュリティ部分）とその中で有効活用できるAWSサービスや仕組み
非機能要求グレードのセキュリティに関する項目とそれに対してAWSサービスやAWSが提供している仕組みを活用してどのように要求事項をクリアできるかをまとめた表が以下です。
| 非機能要求グレードNo | 小項目 | AWSサービス/仕組みの活用と注意事項等 |
|---|---|---|
| E.1.1.1 | 情報セキュリティに関するコンプライアンス | AWSが準拠しているセキュリティ基準については以下に掲載されているのでその内容を確認するようにしてください。 https://aws.amazon.com/jp/compliance/programs/ 責任共有モデルにおいてユーザの責任範囲とされている領域について各基準に準拠する責任はユーザにあるためその点に注意が必要です。 |
| E.3.1.1 | セキュリティ診断 | CSPM（Cloud Security Posture Management)というクラウドサービスのセキュリティ関連の設定ミス・不備をチェックするための機能として、AWS Security Hubが存在します。 これを用いて設定ミス・不備の確認と是正を行います。 https://aws.amazon.com/jp/security-hub/ |
| E.4.1.1 | セキュリティリスクの見直し | ECRでのコンテナイメージスキャンでコンテナに対する脆弱性を発見します。この機能はInspectorとの統合によりOS・プログラミング言語の両方の脆弱性を対象とするスキャンが可能です。ECRリポジトリ単位ではなくリージョン単位で一度拡張スキャン（Inspectorの利用）を選択するだけで複数のECRリポジトリを対象にできるので、AWSアカウント開設時点でこの設定をすることで高いセキュリティが運用負荷を上げずに可能です。 その他アプリケーションデプロイにあたってAWS CodePipline、AWS CodeCommit、AWS CodeBuild、AWS CodeDeployといったサービスを活用してCICDを実現し、その中でセキュリティ関連のテストを組み込むことにより常にセキュリティを担保したアプリケーションのデプロイを可能にすることが推奨です。 セキュリティ脅威に関する最新情報を入手できるようCVEリストの確認を行い、特に高いセキュリティの実現が求められる場合にはAWS Shield Advancedを利用することを検討することが必要です。 AWSに関するセキュリティ情報はAWSセキュリティブログやAWSセキュリティ速報等を用いて定期的に最新情報を入手します。その結果得られた情報やSecurity Hubの検出結果、GuradDiutyが検知した脅威の傾向等を踏まえて脅威に対して優先順位をつけて対応を行います。 AWSの新サービスやセキュリティサービスのアップデート情報を定期的にチェックし新機能の評価・実装を行います。 |
| E.5.1.1 | 認証機能 | (*1) |
| E.5.2.1 | 利用制限 | 作業者に付与するIAMユーザの権限制御に加えて以下の対策を行うことにより不正なアクセスを制御します。 ・ECSタスク等にアタッチするIAMRoleに付与する権限の制御 ・ECSタスクへの外部からの操作を防ぐためECS Execの無効化 ・データベースのテーブル作成等各種作業はAWS Clou9を用いることで外部からの不正なアクセスを防止 ・S3バケットのバケットポリシーによるデータアクセスの制御 |
| E.6.1.1 | データ暗号化 | データ伝送に関して特に対外接続はTLS暗号化を行いHTTPS接続を必須とすることで対応するのが一般的です。その際TLSバージョンは極力1.2以上にすることが推奨です。ALBではセキュリティポリシーごとに対応するTLSバージョンが異なるのでその内容を確認し要件に合うポリシーを選択します。 API Gatewayではカスタムドメインを利用するか自動的に払い出されるデフォルトドメインを利用するかで異なりますが、カスタムドメインを利用する場合にはセキュリティポリシーの選択が可能です、こちらも特に制約がない場合にはTLS v1.2以上のみを利用するポリシーを選択することを推奨します。 ※今回のシステム構成ではInternetからの通信のみを想定していますが、AWS Direct ConnectやAWS Site-to-Site VPNを用いた通信においても同様にTLS暗号化を行った通信を行うことを推奨します。 |
| E.6.1.2 | データ暗号化 | システム内で保管するデータの暗号化に関して、構成図で記載しているデータベース・ストレージサービスのAmazon Aurora、Amazon S3、Amazon ElastiCacheなどは全て暗号化機能が提供されているのでそれを利用して暗号化することが必要です。更にそれとは別にデータベース内部の個々のデータに対して暗号化を実施するケースもあるのでその要否については案件ごとに判断することが必要です。 |
| E.6.1.3 | データ暗号化 | 鍵管理についてはAWS KMSを利用することが一般的です。但し例えばデータベースのパスワード情報等はKMSではなくAWS Secrets ManagerもしくはAWS Systems ManagerのParameterStoreで管理することが一般的なので秘匿情報を全てAWS KMSで管理するわけではないという点は注意が必要です。 |
| E.7.1.1 | 不正監視 | (*2) |
| E.7.1.3 | 不正監視 | Amazon GuardDutyを用いて外部からの脅威を検出します。 GuardDutyで脅威を検出した際にAmazon SNS等と連携することでアラート通知を行います。 |
| E.7.1.4 | 不正監視 | API GatewayやALBのアクセスログ、VPC Flow Logs等を用いて通信状態を把握します。 |
| E.8.1.1 | ネットワーク制御 | 今回の構成では（構成図に明記していませんが）セキュリティグループによる制御が必要です。 その他、仮にAPI通信についてシステム間通信にするなどの理由で特定送信元のIPアドレスからのみ通信を許可する場合にはAWS WAFで制御を行います。 また、構成図の通りアプリケーション（コンテナ）が直接外部から攻撃されることを防ぐため、パブリックIPアドレスを持つのはVPCの中ではALBとNAT Gatewayのみに限定し、それ以外は別サブネットでプライベートIPアドレスのみを保持することや、ルートテーブルで設定するルーティング上データベースがVPCの外部と通信するルートを持たない等により外部からデータベースへ直接のアクセスを禁止します。 |
| E.8.2.1 | 不正監視 | 外部からのポートスキャン等に対してはAmazon GuardDutyで脅威を検知します。 |
| E.8.3.1 | サービス停止攻撃の回避 | DDoS攻撃に対してはAWS Shieldで対応します。 また、特定送信元からの大量通信に対してはAWS WAFでそのIPアドレスからの通信を遮断します。 |
| E.10.1.1 | Web実装対策 | セキュアコーディングに関してはAWS上でアプリケーションを稼働させる場合でも変わらず必要です。 |
| E.10.1.2 | Web実装対策 | AWS WAFを導入することで対応が可能です。 WAFに関しては導入するだけでは十分ではなく適切に運用を行うことが必要です。その具体的な内容についてはこちらを参照ください。 https://qiita.com/h_nide/items/4ec63dfbf1a464bb5003 |
*1,2 : 表に記載するには長いため別出しで記載します。
E5.1.1 中項目：アクセス・利用制限 小項目：認証機能
E5.1.1の小項目説明は以下の通りです。
資産を利用する主体（利用者や機器等）を識別するための認証を実施するか、また、どの程度実施するのかを確認するための項目。
複数回の認証を実施することにより、抑止効果を高めることができる。
なお、認証するための方式としては、ID/パスワードによる認証や、ICカード等を用いた認証等がある。
この項目に対してAWSを以下のように活用することで高いセキュリティを担保することが可能です。
-
本番環境/開発環境等、環境用途ごとにAWSアカウントを分離することで本番環境にアクセスできる権限を分離することが推奨です
-
アプリケーションのユーザ（アプリケーション内の権限でいう管理者を含む）に対する認証はアプリケーション内部で認証機能を設ける、もしくはAmazon Cognitoを用いて実施します
-
AWS環境に対してシステムメンテナンス等の目的でアクセスするユーザに対する認証はIAMを用います。IAMに関してはAWS公式で公開されているセキュリティのベストプラクティスに極力準拠することが望ましいです。そのうえで特にシステムリリース前の初期構築段階でIAMUserの権限を厳密に絞ると作業都度様々な場面で権限不足となり作業遅延につながるリスクが高いため以下のような流れで段階的に権限を制御していく方法を推奨します
【AWSアカウント開設時点】
Rootアカウントを用いてAdmin権限を保有するIAMUserを作成する
↑上記作業を行った後Rootアカウントは利用しないようにする、Rootアカウントのパスワードの保有者とRootアカウントのMFA保有者を分けるなどして複数名が協力しないとRootアカウントを利用できない状態にする【環境構築時点】
・以下3種類程度権限を分けてIAMGroupを準備する
①. Admin権限を保有するグループ（主にAWS環境を構築するインフラ担当者などがこのグループに所属）
②. ECSやAPI Gateway等アプリケーションに密接に関連するAWSサービスのみ操作する権限を保有するグループ（主にAWS上で稼働するアプリケーション担当者等がこのグループに所属）
③. 各AWSサービスの読み取り権限のみを保有するグループ（セキュリティ監査等で環境設定を確認する必要がある人や、SI案件等でユーザ企業様が必要に応じて環境情報をご覧になる場合にこのグループに所属）【システムリリース後】
・以下のように権限を分けてIAMGroupを準備する
①. Admin権限を保有するグループ
②. Admin権限を持ちつつ各AWSリソースに対する削除はできないよう制御されたグループ
③. ECSやAPI Gateway等アプリケーションに密接に関連するAWSサービスのみ操作する権限を保有するグループ
④. 各AWSサービスの読み取り権限のみを保有するグループ
IAMUser単位で①～④のどこに所属させるのかを精査して必要最小限の権限のみを付与するようにする。 -
AccessKey/SecretKeyは極力払い出しをせず、やむを得ず払い出す場合には一時的な認証情報を試用することや、定期的にローテーションすることでセキュリティ対策を行うことが推奨です
-
各IAMユーザはMFAの使用を必須にして、そのうえでパスワード長を十分長くする/パスワードの定期的な変更を要求するなど適切なパスワードポリシーを用いて不正利用を防止することが推奨です
-
定期的なIAMユーザの棚卸し等を行い常に適切なアクセス権限の設定が実現されている状態にすることが必須です
E7.1.1 中項目：不正追跡・監視 小項目：不正監視
E7.1.1の小項目説明は以下の通りです。
不正行為を検知するために、それらの不正について監視する範囲や、監視の記録を保存する量や期間を確認するための項目。
なお、どのようなログを取得する必要があるかは、実現するシステムやサービスに応じて決定する必要がある。
また、ログを取得する場合には、不正監視対象と併せて、取得したログのうち、確認する範囲を定める必要がある。
この項目に対してAWSを以下のように活用することで高いセキュリティを担保することが可能です。
構成図に記載の構成では以下のようなログを収集可能です。
- コンテナログ（アプリケーションログ） : ECSタスク定義の設定でAmazon CloudWatch Logs等に出力
- DNSクエリログ : Amazon CloudWatch Logsに出力
- WAFログ : CloudwatchLogs/S3もしくはKinesisで外部に出力
- API Gatewayアクセスログ及び実行ログ : Amazon CloudWatch Logsに出力
- ALBアクセスログ : S3に出力
- AuroraDBログ : Amazon CloudWatch Logsに出力
※DBに関してはログの他にイベント通知が可能 - VPC Flow Logs : Amazon CloudWatch LogsもしくはS3に出力
- S3アクセスログ : S3に出力
- AWS環境に対するユーザのアクティビティログ : CloudTrailで管理、S3に出力
ログの分析に関して、Amazon CloudWatch Logsの場合はCloudWatch Logs Insightsで対応が可能、S3に保管されるログについてはAmazon AthenaやAmazon QuickSight等を用いて分析が可能です。
ログ収集に関して、セキュリティ上は全てのログを取得する方が良いと考えがちですが、大量のログを収集するとコストに影響することに加え、ログが多すぎると分析が煩雑になり適切に扱えない恐れがあります。以下のような点を意識して収集/管理することが推奨です。
①. DNSクエリログについて大量にアクセスのあるシステムにおいてはログも大量に出力されるのでその要否を検討する
②. WAFログについて、全量取得するとログ量が膨大になりえる場合は一定の条件（BLOCKやCOUNTに該当するアクセスなど）で絞ることを検討する
③. VPC Flow Logsは特にログ量が膨大になりやすいので、分析用途を明確にして必要な項目のみ取得することを検討する
④. S3アクセスログなど多数の細かいログファイルをAthenaで分析する場合、ログファイル同士をマージするなどして1ファイルの容量を大きくしてファイル数を減らすことを検討する(*)
➄. アプリケーションログについてログレベルを適切に設定し、不要なログが大量に出力されないようにする
*. 特にAthenaでは細かいファイルを多数検索すると検索効率が悪くなりますので、ファイル数を減らす工夫を行うことで分析をスムーズに行うことができます。
また、特にS3にログを格納する場合、ログの改ざん防止を行うためにログ格納用S3バケットにはオブジェクトロックを有効にしておきましょう。
上記に記載した通り、AWSサービスをうまく活用することで非機能要求グレードの様々な項目に対して効率的に応えることが可能です。
まとめ
今回は日本のシステム開発案件で使われることの多い非機能要求グレードに対してAWS Well-Architected Frameworkとのリンク付け及びAWSサービスを活用してどのように対応できるのか、セキュリティにフォーカスして解説しました。
非機能要求グレード自体非常によくまとまったものですが、クラウドを有効に活用して良いシステムを作るためにはクラウドを使いこなすためのプラクティスを考慮に入れることが重要ですのでセキュリティに限らず非機能全般について非機能の要件検討や設計の際にはAWS Well-Architected Frameworkの内容を踏まえることを推奨します。