Amazon Web Services ブログ

据付時適格性評価（IQ）ステップの自動化、GxPコンプライアンスの迅速化

この記事は “Automating the Installation Qualification (IQ) Step to Expedite GxP Compliance” を翻訳したものです。

 

GxP ガイドラインは、米国食品医薬品局 (FDA) によって制定され、ライフサイエンス分野の企業が安全で、品質ガイドラインを満たし、使用に適した製品を開発、製造、販売することを目指しています。GxP コンプライアンスは、長年にわたりライフサイエンス業界が従うべき規制の一部であり、ヘルスケア業界やライフサイエンス業界のお客様が品質管理システムの一環としてコンピュータシステムを展開する必要がある場合に大きく影響しています。重要なポイントの1つは、コンピュータシステムの認定とバリデーションの必要性です。通常、お客様はオンプレミスでこれを行う方法に精通していますが、クラウドに関してはその方法に不案内な場合があります。バリデーション計画を作成して実行するプロセスは、従来、手作業で労力を要していました。この記事では、バリデーション計画の最初のコンポーネントの1つである据付時適格性評価 (Installation Qualification : IQ) を自動化できるアプローチを提案します。

GAMP 5 のGxP準拠のコンピュータ化システムへのリスクベースアプローチによれば、据付時適格性評価 (IQ)とは、システムが事前に承認された仕様に従ってインストールされていることをバリデーションし、文書化することです。バリデーションは、ソフトウェアとハードウェアのインストールと構成が正しいことを証明するテストを行うことで達成されます。この定義を使用して、この自動化という重要な要件の実現を考えてみます。

まず、「事前承認された仕様」について考えてみましょう。 AWS のベストプラクティスとは、インフラストラクチャ・アズ・コード (IaC) のテンプレートを使用して必要なインフラストラクチャを定義することです。このテンプレートは、必要なリソースとその構成について記述しします。環境 (QA/UAT、PRE-PROD、PROD) とリージョンの間で構成がわずかに変更されることがありますが、コアとなる laC テンプレートは変更されません。この柔軟性は、テンプレートのパラメータのおかげで実現されることになります。このテンプレートは、その後、AWS CloudFormation によってリソースをプロビジョニングするために使用されます。

これらのテンプレートは、ソースコードと同様に制御されます。ソースコードリポジトリにそれらを格納することで、テンプレートをバージョンアップし、時間の経過に伴う、その更新の完全な履歴を維持することができます。

先のフレーズのもう一つの重要な部分は「事前承認」です。 お客様が承認を得ようとする方法は多岐にわたります。たとえば、Jira ワークフローやソースコードリポジトリでのプルリクエストの承認などです。お客様の品質ITチームまたはコンプライアンスチームによって審査され、承認される方法が何であれ、最終的な結果としては、ソースコードリポジトリ内の特定のバージョンのテンプレートが承認済みとして記録されます。

さて、デプロイしたいリソースを説明する事前承認済みの仕様が用意されました。承認されると、自動化されたパイプラインがトリガーされ、リソースがデプロイされます。次に、インストールが正しかったことを示すために、次の要件を調べる必要があります。これは、AWS CloudFormation がアカウントに実際にデプロイしたリソースを、ソース管理下にある事前承認済みのテンプレートと比較することによって実行できます。

アプローチ

我々が提案するアーキテクチャは、いくつかの方法でデプロイできます。

  1. 個々のアカウントの自動化
  2. 一元的なセットアップ

独立したアカウント

このアプローチでは、実行されるすべての AWS CloudFormation を継続的インテグレーションおよび継続的デリバリー（CI/CD）パイプラインとに統合し、 IQ の結果を生成できます。このアプローチは、CI/CDパイプラインがすでに使用可能な場合に有効です。CI/CD パイプラインの設定方法の詳細については、 こちらを参照してください 。このアプローチでは、アカウントごとに柔軟にカスタマイズできます。

一元的なセットアップ

この方法では、共有サービスアカウントがソフトウェアのコアをホストします。自動化された IQ を実行する必要があるすべてのアカウントには、サービス共有アカウントでホストされている集中化されたソフトウェアにイベントを送信する CloudWatch ルールと、デプロイされたリソースをクエリするためにすべてのアカウントの自動化を可能にするロールをインストールするだけで済みます。

このアプローチには、管理とアップグレードが一元化されるという利点があります。変更がある場合は、サービス共有アカウントに一度だけデプロイする必要があるのみです。しかし、欠点は、新しいリソースをクエリするために追加のアクセス許可が必要な場合は、それらをすべてのアカウントにデプロイする必要がありますが、これも自動化することができます。

アーキテクチャの概要

Architecture Overview

図1：アーキテクチャの概要

アプリケーションアカウントのフロー :

  1. ユーザーが CloudFormation テンプレートを実行する
  2. これにより、CloudTrail API イベントが生成されます
  3. CloudWatch ルールがトリガーされます

サービス共有アカウントのフロー:

  1. CloudWatch ルールは、さまざまなアプリケーションアカウントからイベントを受け取り、SQS に転送します
  2. SQS はLambda 関数をトリガーします
  3. Lambda 関数は、アプリケーション アカウントで CloudFormation によって作成されたリソースをクエリし、ベースラインと比較します。
  4. 結果を JSON として DynamoDB に保存します
  5. IQステップが合格したか、失敗したかを評価します。コンプライアンスの問題が見つかった場合は、IQステップを失敗と評価し、SNS 経由で通知を送信します
  6. リソース、プロパティ、アラート、コンプライアンスのJSONを作成し、それを S3 バケットに格納します
  7. QuickSight で Athena を使用して S3 から JSON を使用し、レポート/ダッシュボードを作成します
  8. “Autodoc generator“ Lambda 関数を使用して、任意で Word ドキュメントを作成し、S3 に保存します

詳細な説明

各アプリケーション アカウントでは、CloudWatch イベントルールは、CreateStack および UpdateStack の CloudTrail API 呼び出しでトリガーされるように設定されます。ターゲットは、サービス共有アカウントの EventBus に設定されます。

アプリケーション アカウントでイベントルールを作成するための AWS CloudFormation スニペット:


spokeAccountIqOqEventSendRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: spokeAccountIqOqEventSendRole
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          Effect: Allow
          Principal:
            Service: 
              - events.amazonaws.com
          Action: sts:AssumeRole
      Policies:
      - PolicyName: send_event_to_shared services_account
        PolicyDocument:
          Version: '2012-10-17'
          Statement:
           Effect: Allow
            Action: 
            - events:PutEvents
            Resource: !Sub 'arn:aws:events:us-east-1:${SharedServicesIQAccountNumber}:event-bus/default'

すべての AWS アカウントには 1 つのデフォルトの Amazon EventBus があり、AWS サービス、カスタムアプリケーション、その他のサービス、アカウントによって生成されたイベントを受信できます。

共有サービスアカウント EventBusPolicy を使用すると、アプリケーションアカウントで設定されたイベントルールから発生した CloudWatch イベントを受信できます。

AWS CloudFormation スニペット共有サービスアカウント EventBus ポリシー:

crossAccountEventBusPolicy:
    Type: AWS::Events::EventBusPolicy
    Properties:
        Action: "events:PutEvents"
        Principal: "{ApplicationAccountNumber}"
        StatementId: "CrossAccountEventBusPolicy"

イベントは Lambda を直接トリガーできますが、Amazon SQS をターゲットとして設定すると、消費するイベントを保存するための、信頼性が高く、スケーラブルなホストキューが得られます。

AWS CloudFormation スニペット共有サービスアカウント CloudWatch イベントルール:

cloudwatchCFeventruleForIqOq:
    Type: AWS::Events::Rule
    Properties:
      Description: Event rule to call SQS on cloudtrail event
      EventPattern:
        source:
        - aws.cloudformation
        detail-type:
        - AWS API Call via CloudTrail
        detail:
          eventSource:
          - cloudformation.amazonaws.com
          eventName:
          - CreateStack
          - UpdateStack
      Targets:
      - Arn:
          Fn::GetAtt:
          - queueIqOqCloudtrailEvents
          - Arn
        Id: TargetForCloudwatchruleiqoq /

Amazon SQS キューのメッセージは、イベントを消費するマルチアカウントリソースコレクターである AWS Lambda をトリガーします。コスト効率の高いソリューションの場合、リソースコレクター Lambda はスタックのステータスと状態に基づいてイベントをフィルタリングします。スタックのステータスが「保留中」または「不完全」の場合は、イベントをフィルタリングし、スタック完了ステータスのイベントのみを処理します。リソースコレクター Lambda は、独自の共有サービスアカウントから CreateStack イベントと UpdateStack イベントをもフィルタリングします。CreateStack イベントと UpdateStack イベントには、スタック ID、スタック名、およびその他の詳細情報が含まれています。これにより、Lambda がアプリケーションアカウントに API 呼び出しを行い、CloudFormation スタックとそのリソースをクエリできます。

サービス共有アカウントの Lambda 関数が、アプリケーションアカウントで作成されたリソースの詳細を取得するためのロールを引き受けることができるように、アプリケーションアカウントレベルで正しいアクセス許可を設定する必要があります。これは、異なるリージョンの分散アカウントで作成されたリソースに関する情報を収集するための一元化されたセットアップの基礎を形成します。

マルチアカウントリソースコレクターである Lambda には、AWS CloudFormation によって作成されたリソースの詳細を取得するために、アプリケーションアカウント内で必要な AWS STS ロールを引き受けることができるロールが割り当てられます。また、監査ログやバリデーションデータなどの追加ログを作成および管理します。

マルチアカウントリソースコレクターである Lambda がアプリケーションアカウントからインフラストラクチャ情報を取得する方法にはいくつかあります。CloudFormation テンプレートの承認済みバージョンが AWS CodeCommit などのコードリポジトリに保存されている場合、Lambdaはそのテンプレートとそのランタイムパラメータをそこから取得できます。別のオプションとしては、Lambdaがアクセスできる S3 バケットにテンプレートを保存することが挙げられます。そこで、Lambdaは、アカウントにデプロイされたリソース/スタック定義をクエリし、その比較を実行して IQ ステップが合格か失敗かを決定します。

CloudFormation パラメータ、インフラストラクチャ、およびリソースプロパティは、CloudFormation API を使用してクエリし、アーキテクチャ図に示すように DynamoDB に格納することもできます。この場合、DynamoDB は承認されたテンプレートのゴールデンコピーとして機能します。これにより、スタックとそのリソースで API 呼び出しを行うことで、カスタムプロパティや詳細なプロパティを含む追加データの永続性が得られます。ただし、このオプションでは、承認された、または「ゴールデン」ベースラインを記録できるように、テンプレートを特定の環境で「非適格」モードで最初に実行する必要があります。その後、同じテンプレートを「適格」モードで実行し、ベースラインと比較します。このアーキテクチャでは、Dynamo DB オプションを使用します。

デプロイされたインフラストラクチャのプロパティは、動的プロパティまたは静的プロパティに分類できます。たとえば、EC2 インスタンスの「パブリック IP アドレス」プロパティはリージョンで用いられる「AMI ID」が静的プロパティとして分類されるのに対し、「パブリック IP アドレス」は変更される可能性があるためです。 動的プロパティの場合、プロパティの存在が確認され、静的プロパティの場合は実際の値が比較されます。監査のために、結果は DynamoDB にも保存されます。

結果の比較データは、制御された Amazon S3 バケットに JSON 形式で保存されます。比較データには、リソースのプロパティおよび比較の状態の情報が含まれており、さらなる分析に使用でき、他のサービスと統合して、より優れたレポート、監視、分析を行うことができます。たとえば、Amazon Athena を使用して、標準ベンチマークからのリソースの差分に関するクエリと結果を得ることができます。

( オプション) IQ ドキュメントジェネレータ

ドキュメントの利用に関して補足情報です。コンピュータシステムバリデーションで証跡ををキャプチャするためにドキュメントはを利用することは既定の形式でした。しかし、それらはJSONファイルにキャプチャされた同じレコードの単なる別の形式です。これらの JSON ファイルは、ドキュメント管理システムのドキュメントよりも優れていない場合、同様に制御できます。JSONが十分に物理的に読める形式であると見なされない場合、レポート出力はJSONを別の形式に変換するより良いオプションです。この変換は、デフォルトのステップとしてではなく、必要なときに実行できるため、ドキュメント管理の負担を完全に排除できます。

ただし、何らかの形式のドキュメントが義務付けられているSOPをお持ちのお客様は、テンプレートに基づいてIQドキュメントの作成をトリガーできます。

Amazon S3 ソースバケットでの JSON ファイルの作成は、別の AWS Lambda（Autodoc generator）をトリガーしてドキュメントを生成するために使用できます。Autodoc generator Lambda は JSON ファイルを読み込んで、より読みやすく、見やすい Word ドキュメントにフォーマットします。この Word ドキュメントは、コンプライアンスの証明と文書化に使用できます。

図 2: Word ドキュメントを示す S3 バケット

このアーキテクチャ全体は、サーバーレスおよびイベントベースのアーキテクチャです。Python docx のような標準ライブラリはどれでも使用でき、生成された docx は Amazon S3 出力バケットに格納されます。SOPによって義務付けられているお客様の場合は、ドキュメントをドキュメント管理システムに移動できます。

図 3: 自動生成された Word ドキュメント

セキュリティに関する考慮事項

以下に関してはマルチアカウント設定であるため、アプリケーションアカウントとサービス共有アカウントには必要な Amazon IAM ポリシーのみが付与されるように、特別な注意が必要です。まず、アプリケーションアカウントはサービス共有アカウントにイベントを送信します。このため、サービス共有アカウントは、イベントを受信する各アプリケーションアカウントにアクセス権限を付与する必要があります。新しいアプリケーションアカウントが追加されるたびに、CloudWatch のデフォルトの Amazon EventBus アクセス許可を追加する必要があります。これを自動化された方法で完了させるために、アカウントのブートストラップを検討してみてください。

サービス共有アカウントがアプリケーションアカウントにアクセスして、リソースをクエリします。すべてのリソースをクエリするには権限が必要ですが、関心のあるサービスのみ、または使用が承認されているサービスのみを許可します。また、サービス共有アカウントがアプリケーションアカウントのリソースを絶対に変更できないように、アクセス許可をリスト/取得に制限する必要があります。また、他のリソースがアプリケーションアカウントのクエリを開始できないように、これらのアクセス許可は、サービス共有アカウントの Lambda 関数 ARN に制限する必要があります。

JSON とオプションの Word ドキュメントを保存する S3 バケットでは、最小特権という原則に従います。オブジェクトレベルのアクセス許可は、CloudFormation テンプレートの所有者に付与できます。または、これらのオブジェクトにアクセスするためのダッシュボードアプリケーションを作成し、アクセス権限は個別に設定できます。

まとめ

このブログ記事では、コンピュータ化システムバリデーションの据付時適格性評価の手順を自動化するために使用できるアーキテクチャを示しています。このアーキテクチャは、仕様に従ってデプロイが行われたことを示す適切な証拠を作成するために、お客様のSOPに準拠して使用する必要があります。

ホワイトペーパー「 GxP システムで AWS 製品を使用する場合の考慮事項」は、GxP コンプライアンスのために考慮する必要があることを理解するために読んでください。そこには、アカウントごとのセットアップ方法であり、 CI/CDパイプラインが定義されている社内で開発されているソフトウェアに適しているアーキテクチャを解説するブログ記事もあります 。

AWS での GxP コンプライアンスの詳細については、 GxP コンプライアンスページをご覧ください 。また、AWS マネジメントコンソールにログインした後、 AWS Artifactから GxP 関連のアクセスコントロールされたドキュメントをダウンロードすることもできます。

 

著者について

Jiten Dedhia

Jiten Dedhia は、ソフトウェア業界で20年以上の経験を持つクラウドアプリケーションアーキテクトです。彼は、グローバルな製薬および金融サービスのお客様と協働して、AWS への移行とオンプレミスおよびクラウドシステムのアーキテクチャに関するアドバイスを提供してきました。

Manoj Pathak

Manoj Pathakは、クラウドネイティブアプリケーションにおける10年以上の経験を持つクラウドアプリケーションアーキテクトです。専門は、クラウドネイティブアプリケーションのマイグレーションやモダナイゼーション、Devops カルチャーとマイクロサービスです。

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