GxP ワークロード向けに AWS サービスを承認するには

この記事は “Approving AWS services for GxP workloads” を翻訳したものです。
（訳者注1：この記事における「承認」とは、お客様自身が、自身のワークロードにおいて AWS を利用できるか承認する行為のことを指します。）

このブログ記事では、GxP ワークロードの一部として AWS サービスの利用を承認するための承認プロセスの最初のステップについて説明します。このプロセスは、業界ではサービスの「ホワイトリスト化」と呼ばれることもあります。GxP 要件を満たす必要のある AWS のお客様の中には、開発者がどの AWS サービスにアクセスするか制御したい場合もあるでしょう。また、AWS をサプライヤーとして承認する際は、AWS の認証（訳者注2参照）・品質システム・管理情報をもとに評価しますので、GxP ワークロードの開発者には、認証の範囲内のサービスのみを利用できるようにさせたい場合もあるでしょう。一方で、イノベーションを加速させ開発者に高い自由度を与えるため、適度なバランスをとることも重視されています。このブログでは、GxP ワークロード向けの AWS サービスの承認プロセスを、一般的なシステム開発にスムーズに適用する方法もご紹介します。
（訳者注2：ここで、「AWS の認証」とは、AWS が取得している第三者認証（ISO/IEC27001等）のことを指します。）

AWS 自体は GxP 規制の直接の対象となりませんが、セキュリティなどのコンプライアンスは AWS とお客様の間で責任を共有しています。お客様の多くにとって、社内であるサービスを使用する承認を得ることは、組織のシステム構成のガバナンスの一部であると同時に、GxP 対応への重要な第一歩でもあります。規制の観点からも同じことが言えて、AWS の各サービスにおいて、責任共有モデルのうち AWS 側の責任が果たされているかどうかを確認することで、GxP 対応へとつながります。AWS の各サービスが ISO、SOC、HIPAA などのさまざまな認証などに対応しているかを確認することで、AWS 側の責任がどのように果たされているかを知ることができます。

お客様が、開発チーム向けにどのサービスの利用を承認するか決める際、複数の規制を考慮することがほとんどでしょう。検証用の AWS 環境ではすべてのサービスを承認したとしても、HIPAA 準拠のアプリケーション用の AWS 環境では HIPAA 対応のサービスだけに制限したいという場合もあります。このように、AWS の各サービスが対応している複数の認証を考慮に入れながら、サービスを承認するかどうかの判断をおこないます。実際にサービスを承認した後、それらのサービスだけを使うように AWS 環境の設定をおこなうには、AWS Organizations と Service Control Policy をご利用いただけます。HIPAA 対応の AWS アカウント環境を設定するための詳細な方法については、過去のブログ記事をご覧ください。

AWS のあるサービスが認証を取得していること、つまり責任共有モデルのうち AWS 側の責任が果たされていることが確認できると、次のステップとしては、責任共有モデルのうちお客様側の責任をどのように果たしていくかを考えることになります。これを達成するために、多くのお客様では、リスクアセスメントを実施し、AWS のサービスの使用を制御するための方法を定義しています。例えば、Amazon S3 のバケットを暗号化する必要がある、というルールを AWS 環境で実装するには、AWS Config を使用したり、Cloud Custodian などのサードパーティーのツールを使用したりすることで実現できます。これらのツールを使うことで、AWS サービスが正しく設定されているか確認し、仮にルールから逸脱した場合もさまざまなアクションを実行できます。この S3 の例で考えると、もし S3 バケットが暗号化されていなかった場合、アラートを通知したり、自動的に修復するための AWS Lambda 関数をトリガーしたりすることでルールに対応することができます。

プロセスと組織

AWS 環境の制御の自動化について考える前に、社内のサービス利用承認プロセスの実現方法について少しだけ触れておきます。この承認ステップは、GxP 対応のワークロードの開発に必要な、連続したプロセスの一部であるため、多くのお客様はこれが潜在的なブロッカーになるのではないかと考えています。例えば、ある開発チームで、ワークロードの設計段階を経てテストする段階になってはじめて、サービスが社内で承認されておらず開発には使えないとわかることもあります。必要なサービスを社内で承認してもらおうとしても、別のチームが承認プロセスを終えるまで待たなければならないこともあります。こうした状況に見舞われたことのある開発者は、次からは承認プロセスをより早く始めようとしますが、そうすると担当者がリクエストで手一杯になってしまいます。

こうした状況を避けるためにも、担当者は、承認プロセスなどの規制対応の作業を、受け身ではなく能動的に実施するべきです。つまり、承認プロセスが開発プロセスの中でクリティカルパスにならないようにし、開発チームからそうした過程が見えるように実施することが必要です。これを、お客様社内におけるクラウド推進組織（Cloud Center of Excellence; 以下 CCoE）で実践する方法として、開発用の AWS アカウントでのサービスの使用状況をモニタリングしておくというものがあります。CCoE が開発用の AWS アカウントに直接アクセスできる場合は起動しているサービスを分析してもよいですし、CloudTrail ログにアクセスできる場合はログを分析するのもよいでしょう。そこで得られた使用中のサービス一覧を、承認済みのサービス一覧と比較し、差分を今後のタスクに追加することができます。さらに、開発チームと連携すれば、今後取り組むタスクの優先順位付けをおこなうこともできます。これによって、開発チームがサービスの初期設計や構築作業をしていて、テスト・検証・本番用など制約のある AWS 環境を使い始める前に、CCoE がサービスを調査して承認することができます。そのため、承認プロセスが開発プロセスにおけるブロッカーにならずにすむというわけです。また、このように能動的に承認プロセスを回していくことで、CCoE は承認プロセスの進め方の計画を立てたり、優先順位付けをおこなったりできるようになり、大量の承認リクエストの対応に追われずにすみます。

コンプライアンス管理の自動化

ここまでで述べたように、承認プロセスには、モニタリングをしつつ逸脱が検出されたら対応をおこなう、というコンプライアンスを満たすための管理方法を認識することも含まれます。このようなコンプライアンス管理を実装する方法はいくつかあります。

その方法の１つに、AWS リソースの継続的なモニタリングができる AWS Config があります。これにより、リソースの設定と変更の評価・監査・記録が簡単におこなえます。AWS Config では、AWS リソースの準拠すべきルールを事前に設定して、それに沿って構成変更が行われているかを評価します。ルールの中には、例えば、Amazon Elastic Block Store（Amazon EBS）ボリュームの暗号化、リソースの適切なタグ付け、多要素認証（MFA）の有効化など、さまざまなセキュリティ上の問題に対処するための多数の AWS マネージドルールが用意されています。また、AWS Lambda 関数を使用して、カスタムルールを作成し、それをコードとして記述することもできます。

続いて、Amazon S3 を使用した例も紹介しましょう。Amazon S3 のバケットで、パブリックアクセスを許可するという変更がおこなわれたかどうか監視し、必要に応じて対処する方法について説明するブログもあります。また、そのほかにも、AWS Security Hub と統合できる Cloud Custodian を使用することもできます。Cloud Custodian のポリシーは、単純な YAML の設定ファイルで記述され、ユーザーはリソースの種類（Amazon EC2、Amazon S3、Amazon Redshift、Amazon Elastic Block Store（Amazon EBS）、Amazon RDS など）に従ってポリシーを指定できます。また、その YAML ファイルはフィルターとアクションという項目で設定を記述できます。詳細については、こちらのブログを参照してください。

承認プロセスの一環として、GxP における統制は、監査証跡・電子記録・電子署名・データ完全性・データの暗号化/プライバシー・バックアップなどのコンプライアンス要件のさまざまな面をカバーしていると考えることができます。こうした GxP における統制を考えることは AWS サービスの承認につながるとともに、これらの各コンプライアンス要件は、Cloud Custodian ポリシーに変換できます（以下の例を参照）。

Amazon S3 バケットに対して Cloud Custodian ポリシーを実行する手順を以下に示します。

ステップ 1: コンプライアンス要件を定義する
Amazon S3 バケットを承認するのに必要なコンプライアンス要件を定義します。ここでは、例えば、「個人情報や顧客の機密情報は、記録媒体やデバイスに保存されるたびに暗号化する必要がある」としましょう。

ステップ 2: Cloud Custodian ポリシーを作成する
この要件を満たすために、以下に示されているように YAML 形式を使用して、Cloud Custodian ポリシーを記述できます。

policies:
  - name: s3-bucket-encryption-compliance
    description: |
      Detect the unencrypted S3 Buckets and apply AES256 bit encryption 
      based on the event CreateBucket/DeleteBucketEncryption
    resource: s3
    mode:
      type: cloudtrail
      events:
        - source: s3.amazonaws.com
          event: CreateBucket
          ids: "requestParameters.bucketName"
        - source: s3.amazonaws.com
          event: DeleteBucketEncryption
          ids: "requestParameters.bucketName"          
    filters:
      - type: bucket-encryption
        state: False
    actions:
      - type: set-bucket-encryption
        crypto: AES256
        enabled: true

ステップ 3: 必要な AWS IAM アクセス許可を設定する
Cloud Custodian を実行するためには、 securityhub:BatchImportFindings というアクションが実行できるように許可する必要があります。AWS の認証情報がこのアクションを許可していない場合は、既存のカスタマー管理ポリシーに追加するか、新しい AWSSecurityHubFullAccess という AWS 管理ポリシーをアタッチします。
もし IAM ユーザや IAM ロールが arn:aws:iam::aws:policy/AdministratorAccess または arn:aws:iam::aws:policy/PowerUserAccess のいずれかのポリシーを持つ場合は、すでに必要なアクセスが許可されています。

ステップ 4: マルチアカウントの実行
上記のポリシーは、c7n-org を使用して、複数のアカウントにデプロイできます。c7n-org は、Cloud Custodian を並行して複数の AWS アカウントに対して実行するためのツールです。マルチアカウント環境で Cloud Custodian を実行する方法の詳細については、こちらのリンクをご参照ください。

ステップ 5: Security Hub のコンソールで結果を表示する
他のサービスについても、同様のポリシーを構築できます。他のさまざまな AWS サービスを技術的に制御するポリシーについては、GitHub を参照してください。

まとめ

このブログでは、お客様社内で AWS サービスがレビューを経てアプリ開発チームによる利用が承認されるに至るまでのプロセスについて説明しました。また、効率的な承認プロセス作りを通して、開発チームがコンプライアンスに準拠するための負担を減らす方法についても取り上げました。こうすることで、開発チームは規制の事前承認を待たずに、価値提供により集中できるようになります。最後に、CCoE がコンプライアンスチェックを効率化するための自動化の方法も紹介しました。とはいえ、一般的な利用のための AWS サービスの承認をおこなうことは、GxP 規制対象のワークロードでサービスを使用できるようにするための正式な認定プロセスの最初のステップにすぎません。例えば、ISPE の『GAMP 実践規範ガイド：ITインフラストラクチャの管理とコンプライアンス』で示されているようなビルディングブロックの考え方を利用することもできるでしょう。このビルディングブロックは、ひとつの AWS サービスを指すこともありますし、AWS サービスをいくつか組み合わせたものや、サービスのまとまり全体を指すこともあります。これについては、またの機会に説明したいと思います。

著者について

Ian Sutcliffe

Ian Sutcliffe は、主にライフサイエンス業界で IT 分野で 25 年以上の経験を持つグローバルソリューションアーキテクトです。規制業界におけるクラウドのソートリーダーであり、お客様が規制業界でクラウドネイティブなシステムを構築できるよう、IT の運用モデルおよびプロセスの最適化・自動化に重点的に取り組んでいます。

Susant Mallick

Susant Mallick は、AWS のグローバルヘルスケアライフサイエンスのチームにおける業界スペシャリストでありデジタルエバンジェリストです。ライフサイエンス業界での 20 年以上の経験があり、これまでに北米・アジア太平洋・ヨーロッパ・中東・アフリカの製薬企業および医療機器企業と協働してきました。また、さまざまな治療分野のお客様のために、モバイルアプリ・AI/ML・IoT、その他の技術を使用して、多くのデジタルヘルスプラットフォームと患者エンゲージメントソリューションを構築してきました。電気工学の学士号を取得し、金融でMBAを取得しています。彼のソートリーダーシップと業界の専門知識は、製薬業界フォーラムで高く賞賛されています。

翻訳は Solutions Architect の石尾が担当しました。原文はこちらです。

Amazon Web Services ブログ