NIST CSFに準拠したAWSの運用を考えてみた

# はじめに

クラウド環境のセキュリティをNIST CSFを利用し、運用、環境構成、両面でセキュリティ対策を考えてみました。
実際にやってみて大変だったことや、セキュリティ対策を実施する上で役に立ったAWSの機能を紹介していきます。

# NIST CSFとは

米国国立標準研究所が公開している、サイバーセキュリティフレームワークで、
セキュリティ管理手法の概念・管理方針・体制の整備されています。

機能、カテゴリー、サブカテゴリーに分類されており、
環境構成以外にも、サービス運用のセキュリティ対策まで網羅されています。

# NIST CSFの構成

評価用テンプレートの入手方法：
[IPA](https://www.ipa.go.jp/security/publications/nist/)のホームページから、[NIST CSFのテンプレート](https://www.ipa.go.jp/files/000071205.xlsx)をダウンロード。

各カテゴリーの説明：
カテゴリーの説明は、[こちら](https://qiita.com/pankata79/items/db7d0d6b63492747ba11)の記事が参考になるので割愛します。

```
* 識別 (ID)
    * 資産管理（ID.AM）
    * ビジネス環境（ID.BE）
    * ガバナンス（ID.GV）
    * リスクアセスメント（ID.RA）
    * リスクマネジメント戦略（ID.RM）
    * サプライチェーンリスクマネジメント （ID.SC）
* 防御 (PR)
    * アイデンティティ管理、認証／アクセス制御（PR.AC）
    * 意識向上およびトレーニング （PR.AT）
    * データセキュリティ（PR.DS）
    * 情報を保護するためのプロセスおよび手順（PR.IP）
    * 保守（PR.MA）
    * 保護技術（PR.PT）
* 検知 (DE)
    * 異常とイベント（DE.AE）
    * セキュリティの継続的なモニタリング（DE.CM）
    * 検知プロセス（DE.DP）
* 対応 (RS)
    * 対応計画（RS.RP）
    * コミュニケーション（RS.CO）
    * 分析 （RS.AN）
    * 低減（RS.MI）
    * 改善（RS.IM）
* 復旧 (RC)
    * 復旧計画（RC.RP）
    * 改善（RC.IM）
    * コミュニケーション（RC.CO）
```

# やってみた感想
#### 良かったこと
一番は、**計画的なセキュリティ向上のためのロードマップ**が作れたこと。
セキュリティは大切な機能であるが、**優先順位をつけることが難しい**事が多い。

網羅的に、潜在的なリスクを洗い出すことで、
いつまでのどの機能、対策を実施していこうと**期限を明確にして、セキュリティ強化**ができる。

```
* サービスポリシーの明文化ができる
* 文面に起こすことでサービス仕様をより明確にできる
* BCP対策など、災害対応、セキュリティトリアージマニュアルのブラッシュアップができる
* 環境構成上のセキュリティをより向上できる
* 障害復旧、セキュリティ監視機構をより強化できる
```

#### 難しかったこと
具体的な例が少なく、専門的かつ抽象的な表現が多いので、
実際どうするかコンテンツに落とすのに苦労しました。

複数製品運営しているところは、目的や対応例をまとめておくと、
別部署の人がトライするときにハードルが下がるなと思いました。

```
* わかりやすく、体系的な補助コンテンツが少ない
* 内容が専門的かつ、抽象的で読み解くこと、実際に対策に落とすのが難しい
* 100点をすべてでとるのは難しいので、「できれば」「基本」「最低限」などリスクに応じて対応度を決める必要あり
```

# NISTCSFに準拠するために便利なAWSの機能
複数環境の管理、統制を考える上で、
複数環境一括の情報取得、配布、変更が大変だったので、そのときに役に立った機能を紹介します。
※CloudtrailやConfigなどは一般的なので割愛します。

```
* 運用権限の変更、統一、ログ取得
* 予期せぬ変更のキャッチ、修復
* 定期的な棚卸しのための複数環境一括の情報取得、更新
```

#### Organizations
複数アカウントの管理機能。

* AWSアカウントの一元管理
複数アカウントに適用するポリシーを管理できます。
グループを作成し、そのグループに対してポリシーを適応することでサービスへの使用を制限できます。

* サービスのアクセス制御
OU(組織単位) や SCP(サービスコントロールポリシー) を使用ことで
複数のアカウントで使用できるサービスを管理することができます。

* アカウント作成・管理
アカウントの作成・管理を行うことが出来ます。
APIを使用することで新規アカウント発行・グループに追加を行い、すぐに使用することができます。

* 複数アカウントへの一括請求
マスターアカウントを使用して、組織で使用したAWSの費用を統合して支払うことができます。

#### CloudFormation Stack Sets
CloudFormationを利用して、リソース構築ができるサービスです。
1つのテンプレートから複数のAWSアカウント、リージョンに対しStackを作成することができます。
※StackSetsを使うためには、事前にIAMロールの設定が少し手間でした。

#### AWS Config
AWSアカウントにあるAWSリソースの設定を評価、監査、審査できるサービスです。

* AWS Config rules
AWSの設定を監視し、予め決めたポリシーに準拠しているかチェック、アラート通知ができます。
SecurityGroupの変更などセキュリティに影響が大きいものは監視すると便利です。

* Automationドキュメントを利用した修復アクション
上記とセットの機能です。
不適切な変更が行われたり、必要な設定が足りない場合、自動で修復を行うことができます。
新規製品などは、CloudFormationなどを利用し、構築内容をコード管理し、
手動適用を排除することで、設定漏れなど防ぐことができますが、既に運用開始しているサービスにはおすすめです。
※新規製品でも新しいニーズに対する最初の運用は手動だったりもすると思うので、そんなときも有効です。

* Config aggregator
OU内の複数アカウントのデータを1つのアカウントに集約することができます。
AWS Configで収集しているリソースや、Configルールのチェック結果を収集することができます。

* 高度なクエリ
Configで収集したリソースに対して、SQLを発行できる機能です。
上記aggregatorと併用することで、複数アカウントのAWSの情報を一括で取得、検索することができます。

#### AWS SSO
社内で利用しているidpと連携することが可能です。
例えばGoogleアカウントを使用して、AWS管理コンソールにログインすることができます。
また、スイッチロール行える権限を用意しておくことで、用途に応じた権限のユーザを利用することができます。

入退場管理などを各ツール別々ではなく、一括で実施できることで、権限の付与、削除をもれのリスクを低減できます。