Amazon Web Services ブログ

【開催報告】ISV/SaaS のお客様に向けた セキュリティ 勉強会

こんにちは。ISV/SaaS ソリューション本部 Solutions Architect の前田です。

私が所属する ISV/SaaS ソリューション本部では、主に国内のパッケージベンダーや SaaS ビジネスを展開するお客様へ技術的なご支援を無償で行っております。
「どういった相談が出来るのか？」や「過去の具体的な相談内容」についてはこちらのブログ「オフィスアワーで会いましょう！ – ISV/SaaS 事業者向け個別相談会のご案内」をご覧ください。

今回、ISV/SaaS のお客様が自社のサービスにセキュリティサービスをご活用いただくきっかけとして、セキュリティ勉強会とハンズオンを開催しました。このブログでは勉強会の内容をご紹介します。

当日は以下のようなアジェンダで実施致しました。

  • AWS の責任共有モデル
  • 単一の AWS アカウントを安全に使うために知っておくこと
  • 複数の AWS アカウントを安全に使うために知っておくこと
  • AWS の セキュリティサービスについて

それぞれのトピックの一部をこのブログではご紹介します。

AWS の責任共有モデル

AWS を利用する皆様に必ず知っておいて頂きたい「責任共有モデル」という考え方について説明しました。
責任共有モデルは「AWS が責任を持つ範囲」と「お客様が責任を持つ範囲」を明確にし、互いのセキュリティに対する責任を共有し合うことで全体のセキュリティを漏れが無いように高めていきましょうという考え方です。
Amazon Elastic Compute Cloud (Amazon EC2) を例にあげると AWS とお客様の責任範囲は以下の図の様に分類することが出来ます。

現在 AWS では 200 以上のサービスが提供されており、AWS がマネージドで提供する範囲によってお客様の責任範囲が変わります。例えば Amazon Relational Database Service (Amazon RDS) などのマネージドサービスでは Amazon EC2 と比べてお客様が責任を持つ範囲が減り、Amazon DynamoDB のようなサーバーレスのサービスではさらにお客様が担当する範囲が減ることになります。
マネージドサービスを活用することでお客様のセキュリティに関する運用上の負担を軽減し、AWS が責任を持つ範囲と合わせて全体としてのセキュリティを満たすことが出来るようになります。ただし、マネージドサービスを利用したとしても AWS の環境をセキュアに利用するためにお客様側でしっかりと対策を行う必要があります。
次のトピックでは AWS の環境をセキュアに利用するための考え方や出来ることについて単一の AWS アカウント(シングルアカウント)、複数の AWS アカウント(マルチアカウント)の 2 つのケースに分けてお話していきます。

単一の AWS アカウントを安全に使うために知っておくこと

ここでは単一の AWS アカウントを対象に、セキュアに利用するために出来ることをご紹介しました。
AWS 環境を安全に利用するためにまず知っておいて頂きたい内容は「ユーザーの種類」です。AWS における「ユーザーの種類」は大きく分けて 2 種類あります。AWS アカウントの作成に合わせて作られるルートユーザーと言われるアカウントと AWS IAM というサービスを利用して作成することが出来る IAM ユーザーというユーザーです。

これらのユーザーの使い分けとして、まずルートユーザーは極力使用しないことを推奨します。そのため日常的なタスクでは IAM ユーザーを利用するようにしましょう。ルートユーザーを利用する例は公式ドキュメントに記載されている為、ご参照下さい。

ルートユーザーは AWS アカウント内のすべてのリソースへのフルアクセス権限を持った強力なアカウントなので、AWS でのアクセス制御を設定することが出来る AWS IAM による統制が利きません。統制が利かないということは有事の際に権限を剥奪するということが一切出来ないということになります。ほとんどの方は日常的なタスクに、全ての権限が必要になるという場面は少ないと思います。そのため、セキュリティの原則である「最小権限の原則」に則り、必要十分な権限を IAM ユーザーに与え IAM ユーザーを利用するようにしましょう。

また、AWS を利用する方法としては大きく分けて

  • マネジメントコンソール
  • プログラムからのアクセス

の 2 つに分類することが出来ます。
それぞれの方法でセキュアに利用するために出来ることを説明します。

マネジメントコンソール
MFA の有効化をご検討下さい。MFA を有効化しておくことで、万が一パスワードが流出してしまったとしても、MFA で登録したデバイスが盗難されていない限り第三者がログインすることは出来ません。

プログラムからのアクセス
AWS 環境内から AWS のサービスにアクセスする場合、アクセスキーではなく IAM ロールを利用してください。アクセスキーを持っているユーザーであれば誰でも、AWS リソースに対して同じレベルのアクセス権を持つことができるため、アクセスキーが適切に保護されていないと第三者に利用されてしまう可能性があります。
アクセスキーを利用する場合、アクセスキーの定期的なローテーションを行ってください。また、以下のような理由からアクセスキー及びマネジメントコンソールへアクセスに必要なクレデンシャルを複数人で共有することは避けるようにしてください。

  • そのクレデンシャルの権限で誰が操作を行ったのか特定が困難になるため
  • 退職や異動などの理由によりその特定のメンバーのみアクセスを失効させたい場合の運用が困難となるため
  • 流出箇所が増えることにつながるため

複数の AWS アカウントを安全に使うために知っておくこと

マルチアカウントを検討する場合に運用負荷を下げることが出来るサービスの説明や重要な考え方を説明しました。
シングルアカウントで開発環境や本番環境などの様々な環境を構築する場合様々な課題が発生します。

  • 監査を行う対象が一つのアカウントにまとまっている場合、監査を行う対象の絞り込みが困難になる可能性がある
  • VPC の分割はネットワークを分割するのみであり、API レベルでは分離されない
  • 一つのアカウントが抱えるリソースの数が増えていくため、リソースのトラッキングが困難になる

一例ではありますが、これらの課題を解決するために AWS アカウントを複数作成し、マルチアカウントの利用があります。
アカウントを分離することで、これらの課題を解決することは出来ます。しかし同時に、分離したアカウントを管理する手間が発生します。
このアカウント管理の手間を AWS Organizations を利用することによって減らすこと出来ます。例えば、マルチアカウントを運用する場合、お客様自身が保持する AWS アカウントはお客様自身でリスト管理する必要がありました。これらの管理作業は AWS Organizations で実施することが可能です
また、アカウントの横断的な権限設定も Service Control Policy (SCP) という機能によって可能となります。

AWS Organizations でマルチアカウントを管理することによって、セキュリティのベースラインを揃えるのが簡単になります。

  • AWS CloudTrail を有効化することによる API 操作ログの収集
  • ベースとなる IAM ロールの設定
  • Amazon VPC などの Network の設定
  • AWS Config や AWS GuardDuty などのセキュリティサービスを設定することによる AWS リソースの評価やモニタリング

これらの作業をアカウントを作成する度に手動で行うと手間になります。またヒューマンエラーも起こりやすいため、AWS CloudFormation などの IaC サービス、ツールを利用し自動化するケースが一般的です。IaC サービス、ツールを用いてベースラインを揃えることも可能ですが、AWS Control Tower というサービスを利用したり、AWS Organizations のセキュリティサービスとの統合機能を利用することで最低限のベースラインを自動で揃えることが可能になります。
AWS Control Tower にはベースラインの自動設定だけでなく、ガードレールという考え方を元に最低限守りたいルールを設定する機能が備わっています。

現実世界に置き換えて説明すると、高速道路では複数の車線が存在し、中央分離帯によって走行する方向が分かれています。中央分離帯にはガードレールが存在していますが、役割としては命に危険を及ぼす危険な行為である逆走をやめさせるためです。
Control Tower 内で登場するガードレールという用語は大きく分けて 2 つの種類があります。

  • 予防的ガードレール
    • 対象の操作を実施できないようにするガードレール
    • SCP で実装される
  • 発見的ガードレール
    • 望ましくない操作を行った場合、それを発見するガードレール
    • 管理しつつ開発のスピードを上げるために効果的
    • AWS Config Rules で実装される

最低限守って欲しいルールは予防的ガードレールによってきちんと防ぎ、そのうえで発見的ガードレールで望ましくない操作を発見し次に行うべき対応(ルールから逸脱した場合に管理者に通知を送るなど)につなげます。セキュアにマルチアカウントを利用する、かつ運用負荷を下げたい場合は是非 AWS Control Tower の活用をご検討ください。

また、マルチアカウントを利用する場合、AWS アカウント毎に認証情報(ID、パスワード)を発行、管理する煩雑さが課題になります。AWS の場合 AWS Single Sign-On (AWS SSO)を利用することで一つの認証情報で複数のアカウントにログインすることが可能になります。

マルチアカウントを利用する場合は AWS SSO の活用もご検討ください。

AWS の セキュリティサービスについて

最後のトピックでは AWS の様々なセキュリティサービスをご紹介しました。

  • AWS Trusted Advisor
    自動でセキュリティやコストについての問題点を洗い出してくれます(ベーシックおよびデベロッパーサポートはベーシックなセキュリティチェックのみになります。全てのチェックを行うにはビジネスサポート以上が必要になります)
  • AWS CloudTrail
    AWS 上の API 操作を記録するサービス
  • AWS Config
    AWS リソースのインベントリ管理、構成変更管理のためのサービス
  • Amazon Inspector
    ソフトウェアの脆弱性や意図しないネットワーク露出領域を継続的なスキャンで検知する脆弱性管理サービス
  • Amazon GuardDuty
    脅威インテリジェンスと機械学習の分析で脅威検出するサービス
  • AWS Security Hub
    組織内の様々なセキュリティデータを一元的に集約して後続アクションにつなげることができるサービス
    マルチアカウント/マルチリージョン環境のデータを一元的に管理することができる

※各サービスの詳細は各 AWS ドキュメントページや、Black Belt をご参照ください。

【ハンズオン】 脅威検知とその通知を実装する

ハンズオンでは実際に作成した EC2 インスタンスを攻撃し、侵害されたインスタンスの検知から検知内容の通知をユーザーに送る一連の流れを体験しました。

相談会

勉強会当日は個別相談会も実施致しました。相談会では、お客様の AWS 環境でのセキュリティ対策に対するレビューや勉強会で説明した AWS Control Tower についての詳細な設定についてご相談頂きました。この相談会は個別に時間を設定して実施することも可能です。相談会に関してはこちらのブログ「オフィスアワーで会いましょう！ – ISV/SaaS 事業者向け個別相談会のご案内」を参照ください。

まとめ

今回のブログでは セキュリティ勉強会の内容を一部ご紹介しました。
当日の資料や動画は以下からダウンロード、閲覧して下さい。

セキュリティサービスの導入に関するご相談やお客様の環境をレビューしてほしいといったご相談はぜひご連絡ください。
お客様の担当営業もしくはこちらからお問い合わせいただければ、Solutions Architect がお客様の課題解決に向けてご支援いたします。

このブログの著者

前田 駿介 (Shunsuke Maeda)
ソリューションアーキテクトとしてお客様の技術支援を行っています。好きなサービスは Amazon Cognito です。好きな食べ物は、カレーです。