パブリッククラウド（AWS、GCP）利用におけるセキュリティ向上の取り組みについて

こんにちは、インフラエンジニアの天津です。
技術本部で主に当社サービスにおける非機能領域のQCD向上や開発生産性向上をミッションとして業務を行っています。

今回は、弊社エンジニア組織でのここ数年のセキュリティに関する取り組みについてご紹介したいと思います。

背景・モチベーション
取り組みの紹介
取り組みを振り返って
これから取り組もうとしている人へ
まとめ

背景・モチベーション

弊社では以前から主にオンプレミスの環境を使用していましたが、ここ数年でパブリッククラウドの利用を推進しており利用率が高まっています。
それぞれのパブリッククラウドでアカウント管理などについては全体で統制を図る仕組みを整備してきていました。

しかしながら、セキュリティに関して全体での取り組みは権限の統制など一部にとどまり、マネージドサービス毎のリスク対策については個別のアカウントごとに対応するなど全体で統一した対策が取れていない状況でした。

また、世間的にもクラウド利用に起因したセキュリティインシデントが増えてきており、弊社としてもセキュリティリスクへの対応について議論され始めていました。

そういった状況の中、自分が所属する組織にてパブリッククラウドの利用におけるセキュリティレベルの向上を目的に取り組みを開始しました。

取り組みの紹介

ここからは実際の取組みを紹介していきます。

プロジェクト開始からの全体的な実施内容は下記の通りです。

順次実施していきましたが、一部並行して進めたり、現在も継続している取り組みもあります。

現状把握
パブリッククラウド利用におけるセキュリティ基準の策定
ルール化とルールに沿ったセキュリティガードレール敷設
ルールに対する非準拠状況への対応
セキュリティ基準の講習実施
パッケージ脆弱性に対する取り組み
DevSecOps 導入の取り組み

一つずつ説明していきます。

現状把握

セキュリティレベルの向上を目指すためには現状を知る必要があります。把握のために、それぞれのパブリッククラウドで使用できるセキュリティサービス(※1)を使用しました。

また、AWS Security Hub で検知した結果を見やすくするため、BigQuery と Looker Studio を利用したダッシュボードなども作成し把握を進めました。

その結果、多数の項目についての非準拠があることがわかりました。

検出結果の可視化については、以前にも当社エンジニアブログで紹介していますので合わせてご覧ください。

※1: AWS: Security Hub、GCP：Security Command Center（standard）を活用

パブリッククラウド利用におけるセキュリティ基準の策定

全体的な現状を把握し、今後の対応を検討しました。

非準拠の対応を個別に進める事も考えつつ、パブリッククラウド利用において守るべきことを定める取り組みを進めることにしました。

進め方については、利用者であるエンジニア組織の役職者や、コンプライアンス担当部署を巻き込んで進めていきました。
こういった取り組みが形骸化しないためにもトップダウンかつ継続的な対応を実施していくことが重要だと考えたためです。

今回は守るべきことを定める上で「基準」という枠組みを選択しました。

ルールではなく基準とした部分に違和感を感じる人がいらっしゃるかもしれません。
これには、２つの理由があります。

１つ目は策定の長期間化を危惧したことです。

ルールとした場合罰則や守るための仕組みを整え、合意を得るためには多くの時間を要すと判断し、罰則や仕組みを整備しなくとも始められるものとして「基準」という枠組みを選択しました。
ガイドラインと言い換えても良いかも知れません。

２つ目は形骸化を危惧したことです。

最初からルールとしたとしても、現時点の非準拠が多くある状況下ではたとえ罰則があったとしてもルールが守られない状態が横行し、結果として形骸化することを危惧しました。

これらの理由からまず「基準」を策定することとしました。

策定には２ヶ月ほどの期間を要しましたが、弊社の既存ルールや AWS, GCP のセキュリティに関する文書を参考に 6 カテゴリ、26 項目のパブリッククラウド利用におけるセキュリティ基準を策定し合意を得ることができました。

クレデンシャル管理
1. [全般] 各種クレデンシャルを安全な場所に保管している
2. [全般] 各種クレデンシャルを共有していない
3. [全般] 多要素認証を設定している
4. [SSH秘密鍵] SSHキーペア作成時に弱い暗号方式・短い鍵長を指定していない
5. [SSH秘密鍵] パスフレーズを付与している
6. [SSH秘密鍵] サーバのauthorized_keys内に設定されたSSH公開鍵を定期的に見直している
7. [APIキー管理] 使用しない方法を選択している
8. [APIキー管理] 有効期限を設定、もしくは定期更新を行なっている
9. [パスワード管理] 安全なパスワードを作成している
10. [パスワード管理] 利用サービス個別に作成している
アクセス管理（権限管理）
1. [全般] 定期的に権限を見直している
2. [クラウドの権限管理] 必要最小限の対象・権限を付与している
3. [ユーザの権限管理] 特権ユーザーと運用に使うユーザーを分離している
4. [ユーザの権限管理] 必要最小限の権限を付与している
5. [サービスの権限管理] 必要な場合、アクセス制限を実施する。また、そのアクセス制限が有効か定期的な監視を行っている
ログ管理
1. 監査ログの記録および適切な期間の保管を行っている
2. アクセスログの記録および適切な保管を行っている
3. 各種ログに対して脅威検知の仕組みを実装している
4. 各種ログを一元管理し分析・アクション可能な状態としている
データ保護
1. 保管データを暗号化により保護している
2. 伝送経路上のデータを暗号化により保護している
3. データの保管場所（国・リージョン）を検討し適切な保管場所を選定している
脆弱性対策
1. 使用パッケージ・言語・フレームワークなどに対して定期的な脆弱性チェックを行ない、発見された脆弱性についてのリスク把握・対応を検討する手順およびリスク回避の手段が実装されている。
2. Webアプリケーションに対して定期的な脆弱性チェックを行ない、発見された脆弱性についてのリスク把握・対応を検討する手順およびリスク回避の手段が実装されている。
セキュリティイベント対策
1. セキュリティインシデント対応計画が準備されている
2. セキュリティインシデント対応が定期的にシミュレーションされている

これらから、必要なものを順次ルール化、非準拠の対応を実施していくこととしました。

ルール化とルールに沿ったセキュリティガードレール敷設

基準を策定する前からクリティカルな項目については対応やその対応依頼を進めていました。

その対応をより強制力を持つものとするため、ルール化とそのルールを守るための仕組みの導入を進めることにしました。

ルール化の対象は下記の方針で決めていきました。

AWS Security Hub のクリティカル項目に対してはすべてルール化する
GCP Security Command Center のクリティカルに対してはすべてルール化する
上記以外もセキュリティ基準に則りルール化する

また、守るための仕組みとしてはセキュリティガードレールの考え方を取り込みました。
設定を申請を受けて行うのではなく、ある程度クラウド環境を自由に使ってもらっていいが、ルール非準拠が発生しないように予防する、また、準拠状態に戻すための仕組みが利用者の利便性を損なわないと考えたためです。

ガードレールには下記の２種類があります。ルールに応じて適切なものを選択し実装しています。

予防的ガードレール
- リスクある設定を実施できないよう権限を与えない
  - 対象の例：当社で使用しないリージョンの操作権限
- リスクある設定をほぼリアルタイムで発見し自動的に修復する（発見的に近いが予防に近い形で自動修復されるため予防的に分類）
  - 対象の例：比較的リスクの高いもの、自動修復することでサービス提供に影響が無いもの
発見的ガードレール
- リスクある設定を発見し、通知を行う
  - 対象の例：比較的リスクの低いもの、自動修復することでサービス提供に影響があるもの

ルールとセキュリティガードレールの例は下記のとおりです。

例１
- ルール：バケットレベルでのパブリック公開の設定禁止
- ガードレール：予防的
  - 実装：Config Rule + SSM Automaiton を活用した自動修復(パブリック公開設定を発見次第削除)
例２
- ルール：作成から90日以上経過したIAMアクセスキーの利用禁止
- ガードレール：ハイブリッド（発見的かつ予防的）
  - すべてのIAMアクセスキーを毎日チェックし80日経過から利用者に通知、90日を超えると無効化・削除実施

現在では 31 件のルールとガードレールが敷設されています。

なお、ガードレールは Terraform で実装されており、GitLab-CIによる、定期的なterraform planによりガードレールが壊れていないことも確認するようにしています。

セキュリティガードレールについては以前にも当社エンジニアブログで紹介していますので合わせてご覧ください。

ルールに対する非準拠状態への対応

ルールやガードレールを既に運用されている AWS アカウントに敷設するにあたって注意する点がありました。

それは非準拠状態の解消です。

予防的ガードレールによる自動修復を敷設する場合には、本番環境に非準拠が残存した状態では自動修復した結果サービス障害などの影響が懸念されます。

また、非準拠状態では発見的ガードレールによる通知も多く流れるためため、通知が無視されてしまう状態に陥ることが懸念されました。

そのため、ルール化やガードレール敷設を実施する前に影響の把握と事前の準拠作業を進めていきました。

パブリッククラウドの利用者であるサービス開発運用部署に協力を依頼し、こちらからもリソースを提供して対応を進めていきました。

対応例は次のとおりです。

例１
- ルール：バケットレベルでのパブリック公開の禁止
- 対応：必要な場合はオブジェクト毎の公開設定に切り替え
- 結果：すべてのバケットでバケットレベルのパブリック公開設定が除去できた
例２
- ルール：作成から90日以上経過したIAMアクセスキーの利用禁止
- 対応： IAM アクセスキーのローテーション、または IAM アクセスキーを使用しない方式への転換
- 結果：不要な IAM アクセスキーの削除完了、必要なものはローテーションされる状態、またはアクセスキーを使用しない方式への切替完了
例３
- ルール： EC2 で利用する EBS は暗号化必須
- 対応： EC2 にアタッチされている EBS を暗号化されたものに切り替える