AWSにおけるセキュリティについて

aws security

こんにちは。 auカブコム証券 システム開発部所属の吉井です。

当社のエンジニアリングブログが公開されましたので、 さっそく初投稿です。

はじめに

当社では、事業者向けのkabu.com APIを筆頭に、各種システムの開発環境などがAWS上で稼働しています。 AWS上で稼働する本番環境も増えており、比例して当社システムにおける重要度も上がっています。

AWSを利用するにあたり、お悩みポイントとなりがちなのが「コスト」と「セキュリティ」かと思います。 実際、当社においてもこの2点はよく話題に上がっており、度々議論が行われています。

今回は、このうち「セキュリティ」について書いてみたいと思います。

$ whoami

  • キャリア
    • 大学ではセキュリティ系の研究室に所属
    • 新卒でエンジニア職として働き始めて5年目
    • auカブコム証券にJOINして2年目
  • 担当業務
    • AWSセキュリティ全般
    • 基盤更改案件 など
  • 保有資格
    • IPA 情報セキュリティスペシャリスト
    • AWS Solution Architect Associate
  • 趣味
    • 今月からDTM（DeskTop Music）をはじめました

AWSにおけるセキュリティ

AWSの責任共有モデル

AWSのセキュリティ検討するにあたり、AWSの責任共有モデルを把握する必要があります。

セキュリティとコンプライアンスは AWS とお客様の間で共有される責任です。 この共有モデルは、AWS がホストオペレーティングシステムと仮想化レイヤーから、サービスが運用されている施設の物理的なセキュリティに至るまでの要素を AWS が運用、管理、および制御することから、お客様の運用上の負担を軽減するために役立ちます。 お客様には、ゲストオペレーティングシステム (更新とセキュリティパッチを含む)、その他の関連アプリケーションソフトウェア、および AWS が提供するセキュリティグループファイアウォールの設定に対する責任と管理を担っていただきます。

引用元: https://aws.amazon.com/jp/compliance/shared-responsibility-model/

上記についてEC2を例に考えてみます。

  • EC2が動いているデータセンタおよびサーバ、インターネット回線などは、AWSが管理をしてくれます。
  • 一方で、EC2へのアクセス制御やセットアップされているアプリケーションについては、利用者が管理する必要があります。
  • そのため、アプリケーション自体に対する脆弱性（SQLインジェンクションなど）への対応や、リソースへの不正アクセスについては、利用者側が十分に対策を行う必要があります。

AWSはクラウドサービスなので、設定ミスなどが原因で意図しないリソースが全世界に公開されてしまう可能性もあります。

本記事では、AWSの設定項目などの誤りに伴うリスクを抑えるために活用できるAWSサービスや、その方法について書いていきます。

AWSにおける主なセキュリティサービス

AWSでは、セキュリティを向上させるためのサービスが複数提供されています。 今回は、そのうちいくつかをご紹介します。

AWS CloudTrail

f:id:akyx:20200922164759p:plain

AWS CloudTrailは、AWSアカウントの操作ログを継続的に記録してくれるサービスです。 CloudTrailを有効にすることで、「誰が、いつ、何をしたのか」をログとして残すことができます。

CloudTrailの利用（有効化）自体は無料なので、全てのAWSアカウントに対して有効にしても良いかと思います。 ただし、CloudTrailのログ自体はS3に保存されるため、容量に応じてS3の料金がかかることにはご注意ください。

AWS Config

f:id:akyx:20200922164751p:plain

AWS Configは、AWSの設定内容について評価してくれるサービスです。 ベストプラクティスに沿っていない設定項目や、想定外の設定項目の有無などを定期的に監視することができます。

例えば、Amazon VPCではVPC フローログを有効にすることが推奨されています。 AWS Configのマネージドルールにはこの項目を監視する設定があり、有効にすることで自動的にVPC フローログが有効になっていないVPCを検出することができます。

また、AWS Configには独自のルールを設定できるカスタムルールもあり、各社のルールに従ったチェック項目の実装も可能です。

AWS Security Hub

f:id:akyx:20200922164754p:plain

AWS Security Hubは、複数のAWSサービスからのアラートなどを一元的に管理・表示できるサービスです。 本サービスは、2019年中頃に一般公開されたサービスですが、AWSセキュリティを検討する上で欠かせないサービスとなります。

Security Hubは「マスターアカウント」と「メンバーアカウント」を設定することができます。 両アカウントに対してSeuciry Hubを有効化し、紐付けを行うことで、メンバーアカウントで管理されている項目をマスターアカウントでも確認できるようになります。

Security Hubにはマネージドルールとして、下記3つのセキュリティ基準が用意されています。

  • AWS基礎セキュリティのベストプラクティス
  • CIS AWS Foundations Benchmark
  • PCI DSS

AWS基礎セキュリティのベストプラクティス

AWS基礎セキュリティのベストプラクティスは、AWSが策定したセキュリティ基準です。 具体的には、下記のようなチェック項目があり、積極的に有効化しておくべきものだと思います。

  • VPCにおけるデフォルトのセキュリティグループについて、インバウンドおよびアウトバウンドのトラフィックが有効になっていないか（EC2.2）
  • IAMポリシーについて、フルアクセスを保有するものがないか（IAM.1）
  • RDSスナップショットについて、インターネットに公開されていないか（RDS.1）

その他のルールについては、AWS の基本的なセキュリティのベストプラクティスコントロールをご参照ください。

CIS AWS Foundations Benchmark

CIS AWS Foundations Benchmarkは、セキュリティ標準化に取り組む米国の非営利団体である CIS (Center for Internet Security)が策定したセキュリティ基準です。 具体的には、下記のようなチェック項目があり、こちらも積極的に有効化しておくべきものだと思います。

  • IAMパスワードポリシーがセキュアな状態にあるか（1.5 - 1.11）
  • セキュリティグループの変更を検知・確認できる状態にあるか（3.10）
  • 全世界に向けて22番ポートへの接続を許可しているセキュリティグループがないか（4.1）

その他のルールについては、CIS AWS 基礎ベンチマークコントロールおよびCIS Amazon Web Services Benchmarksをご参照ください。

PCI DSS

PCI DSS(Payment Card Industry Data Security Standard)は、クレジットカード会員の情報を保護することを目的として策定したセキュリティ基準です。 公式ドキュメントにもありますが、本セキュリティ基準を有効化することで、システムがPCI DSSに則したものであると証明できるわけではありません。 PCI DSSには12の要件（Ver 3.2の場合）があり、Security HubのPCI DSSはそれぞれに適合する設定となっているか、の確認の手助けとなるものですので注意が必要です。

Security HubのPCI DSSには、下記のようなチェック項目があります。

  • 全てのIAMユーザについて、MFAが有効になっているか（PCI.IAM.6）
  • CodeBuildのソースリポジトリについて、OAuth認証が利用されているか（PCI.CodeBuild.1）
  • RDSについて、インターネットに公開されていないか（PCI.RDS.2）

その他のルールについては、PCI DSS コントロールをご参照ください。

AWSセキュリティにおけるスターターセット

これからAWS環境のセキュリティを検討する場合は、下記の構成をベースに考えて行けばよいかと思います。

f:id:akyx:20200922164601p:plain

  1. セキュリティ管理用AWSアカウント（セキュリティアカウント）を作成し、下記サービスを用意します。

    • AWS Security Hub（マスターアカウント）
    • Amazon S3

  2. 通常のサービスで使用するAWSアカウント（サービスアカウント）では、下記サービスを用意します。

    • AWS Security Hub（メンバーアカウント）
    • AWS CloudTrail
    • AWS Config
    • Amazon GuardDuty

  3. サービスアカウントのSecurity Hubについては、下記のセキュリティ基準を有効にします。

    • AWS基礎セキュリティのベストプラクティス
    • CIS AWS Foundations Benchmark

  4. サービスアカウントのAWS Configのログ出力先は、セキュリティアカウントのS3に設定します。

  5. セキュリティアカウントのSecurity Hubに対して、サービスアカウントのSecurity Hubをメンバーアカウントとして追加します。このとき、セキュリティアカウントのSecurity Hubはマスターアカウントとなります。

  6. 担当者は、マスターアカウントのSecurity Hubで管理されているアラート（Findings）を確認します。

上記設定を行うことで、AWSセキュリティ対策に向けた環境が整うかと思います。 ただし、あくまで最低限の構成となりますので、この点についてはご留意いただければと思います。

Security Hubに連携させるサービスについては、他にもAWSが提供しているセキュリティ関連のサービス（後述）がありますので、自社のセキュリティポリシーと照らし合わせて追加を検討してください。 個人的には、上記構成に後述するAmazon GuardDutyは追加しても良いと思います。

なお、Security Hubで管理されているアラート（Findings）はAmazon Event BridgeやAmazon SNSなどを用いることで、外部サービスに連携することができます。 これにより、各社で管理しているシステムアラート管理システムなどに対して通知を送信し、チケットを起票するなどの実装も可能となります。 その際に「全てのアラートを通知」としてしまうと、大量の通知が届くことになると思いますので、重要度で仕分けするなどの対応を忘れないようにしてください。

AWSにおけるその他セキュリティサービス

主なサービスでは紹介しませんでしたが、AWSには他にもセキュリティ向上を目的とした様々なサービスがあります。 どれもAWS Configと同様にSecurity Hubと連携することができるため、可能であれば有効にしておくべきものとなります。

Amazon GuardDuty

f:id:akyx:20200922164742p:plain

Amazon GuardDutyは、AWSアカウントにおける不正な動作などを継続的に監視してくれるサービスです。

監視内容としては「AWSコンソールにいつもと異なるIPアドレスからのアクセスがあった」「EC2がTorのリレーサーバとして使われている」などがあります。

近年のサイバー攻撃においては、攻撃者はできる限り自身の活動を秘匿する傾向があります。 また、あまり考えたくないことではありますが、内部の誰かがワルイコトを行う可能性もあります。 GuardDutyを有効化しておけば、上記のような事象が発生した際に、早く気づいて対処できるようになります。

Amazon Inspector

f:id:akyx:20200922164746p:plain

Amazon Inspectorは、EC2の脆弱性を診断・検知してくれるサービスです。

継続的にCVEやCISベンチマークに基づいたリスク評価を実施してくれるのに加え、ネットワークの設定についても評価してくれます。 チェック対象となるCVEは適宜アップデートされているため、Inspectorの有効化＆検知への対応を行うことで、常にシステムをセキュアな状態に保つことができます。

Amazon Macie

f:id:akyx:20200922164757p:plain

Amazon Macieは、S3上のデータを機械学習によって機微情報や認証情報を識別し、検出・評価してくれるサービスです。

例を上げると、意図せずに機微情報をS3にアップロードしてしまった場合や、暗号化されていないS3に認証情報が存在する場合などに、Macieがアラートを上げてくれます。 ただし、本記事公開時点では完全には日本語対応しておらず、クレジットカード番号などは検知できても、日本語の住所などには対応していないようです。

当社におけるAWSセキュリティ

現在の状況

ここまでAWSの一般的なセキュリティサービスなどについて書いてきましたが、当社における状況についても触れてみたいと思います。

当社では、各環境ごとにセキュリティ要件を検討し、それに対応したサービス（GuardDutyなど）をアカウントごとに利用していました。 しかし、当社で利用するAWSアカウントは日に日に増えており、検討にかかる総工数も大きなものとなってしまいます。

上記の課題を解消するため、現在当社では「AWSアカウント作成時はこのサービスを必ず導入すること」というルールを策定した上で、アラートなどは特定の「セキュリティ用のAWSアカウント」に集約する運用へ変更する取り組みを行っています。 このようにすることで、開発者はシステム構成やアプリケーション開発に集中でき、管理者は一定のセキュリティ基準が保たれているかを把握しやすくなります。

まだ「どのサービスのどの項目を有効にするか」や「どのような運用とするか」については検討段階ではありますが、実際にカタチになれば本ブログでご紹介したいと思います。

おわりに

本記事では、AWSセキュリティにおけるサービスや構成の紹介を行いました。 セキュリティは企業におけるシステム戦略において非常に重要なものとなります。

ただし、セキュリティの原則として下記があることを忘れてはなりません。

  1. セキュリティと利便性はトレードオフの関係にある。
  2. セキュリティリスクを0に近づけることはできるが、決して0にはならない。
  3. セキュリティリスクを0に近づけるためには、膨大なコストを要する。
  4. リスクの種類によっては、それを把握した上で許容する、という判断も必要。

今回は触れませんでしたが、当然、AWSのサービスは使えば使うほどコストがかかります。 セキュリティ対策として死守すべきラインはどこかなどについては、システム上で提供するサービスおよび取り扱うデータに応じて事前検討しておくことが重要です。

また、上がってきたアラートを全て通知・対応するようにしてしまうと、膨大な工数が必要となります。 これもCritical - Highのものを優先的に対応し、Medium - Lowについては優先度を下げる・あるいは許容する、などの判断が必要となります。

個人的な見解ではありますが、システムにおけるセキュリティとは何らかのサービスを採用・構築して終わりではなく、それを「人が、どの様に考え、どの様に使うか」が最も重要だと思います。 システム的に対策を行うことも重要ではありますが、関係各所との合意やそこに至るまでの過程こそが、セキュリティリスクを0に近づけるために最も重要なことではないでしょうか。

上記を踏まえた上で、本記事が何かのお役に立てれば幸いです。