Chef InSpec を利用した GxP Infrastructure Installation Qualification の自動化

この記事は “Automating GxP Infrastructure Installation Qualification on AWS with Chef InSpec” を翻訳したものです。

はじめに

このブログでは、 Amazon Web Services (AWS) 環境で Infrastructure as Code(IaC) と Chef InSpec を利用した GxP システムバリデーションにおけるインフラストラクチャの据付時適格性評価 (IQ) ステップ自動化について説明します。

GxP における CSV (Computerized System Validation) では、規制対象のワークロードの基礎となるインフラストラクチャへの要件として、クローズドシステムを制御できることが挙げられます。

このブログ投稿では、 AWS 上での GxP ワークロードを実現するためのインフラストラクチャに対するハイレベルでの戦略、自動化、および教訓について述べていきます。また、インフラストラクチャにおけるデプロイと IQ 評価を自動化することで、お客様のクラウドの俊敏性を最大化する方法についても述べていきます。これは、 GxP クオリフィケーションサイクル時間の大幅な短縮に繋がります。

手順書などのドキュメントを利用した管理は、手作業によるドキュメント作成や記載内容の確認に多くの時間や労力が必要です。そして、それらのドキュメントが一度作成されると、特にリリースサイクルがとても短い場合には、ドキュメントを適切な状態に維持することが困難です。この問題が起因となって、例えば機能拡張やバグ修正、機能追加をまとめて一つの大きなリリースとして扱われるようになります。コンプライアンス要件を満たすことは、信頼性が高く、一貫性のあるシステムを提供するための重要な目標です。自動化されたクラウドのクオリフィケーションフレームワークは、 AWS で実行されている GxP システムワークロード全体のコンプライアンスを向上させると同時に、 AWS 環境全体で他の規制対象のワークロードに拡張する機能を提供します。

テスト自動化に役立つAWSサービス

クラウドでのインフラストラクチャデプロイメントの利点の 1 つとして、 IaC を利用した自動デプロイが挙げられます。デプロイの自動化により一貫性と効率が向上し、セキュリティと運用の可視性が向上します。最も重要な点は、デプロイされたインフラストラクチャが適格な状態を継続して維持できることです。 IaC と自動化のツールの例としては、 AWS CloudFormation 、 AWS Cloud Development Kit 、 Terraform 、 Ansible 、 Chef 、 Puppet 、 SaltStack があります。

AWS CloudFormation の概要と IQ における Infrastructure as Code の利点

AWS CloudFormation (CloudFormation) は、開発者および企業が AWS および 3rd Party リソースを構築および管理する際に役立つサービスです。宣言的にリソースを定義・管理することで、開発者および企業はインフラストラクチャがどのような状態になるのか予測可能な状態にします。 CloudFormation ではインフラストラクチャ全体をスクリプト/テキストファイルでモデル化することができます。これらをテンプレートと呼びますが、テンプレートはインフラストラクチャの信頼できる唯一の情報源になり、バージョン管理を行うことでトレーサビリティと監査可能性を提供できます。さらに、インフラストラクチャの展開をスクリプト化し、バージョン管理することで、継続的なコンプライアンスと迅速なトラブルシューティングの実現に向けたインフラストラクチャコンポーネントの標準化に役立ちます。

また、 CloudFormation はリソース構築の再現性を担保しています。インフラストラクチャスタック（スタック）は、手動のアクションを実行したり、カスタムスクリプトを記述する必要がなく、サービスが自動でリソースの構築および再構築を行います。スタックを管理するために適切な操作を CloudFormation が決定し実行します。その際にエラーが検出された場合は変更を自動的にロールバックします。

CloudFormation は AWS API を介して AWS サービスと連動します。作成する AWS リソースを JSON または YAML のテンプレートフォーマットで記述し、 CloudFormation はテンプレートに基づいてスタックを作成し AWS リソースを構築します。このスタックとは、単一また複数の AWS リソースをひとまとめとして管理するものとなっています。

Chef InSpec

Chef InSpec はインフラストラクチャのデプロイをテストするためのオープンソースフレームワークです。 Chef InSpec の AWS リソースパックは、 50 以上の AWS サービスをテストするためのテストセット機能を提供しています。 InSpec が提供するテストセットの利点の一つは、コードを 0 から記述したり API を呼び出したりすることなく、読みやすい形式でテストケースを作成することができる点です。これによりリソースのデプロイ後にテストを実施し、実際に設定されている値やリソースの状態が設計通りかどうかを確認することができます。リソースパックは、テストを実施するためにすぐに使える機能のリストも提供しています。

デプロイされたリソースに対して InSpec テストを実施することにより、テストスクリプトの開発と管理の観点から、テストに関する作業が簡素化されます。例えば、デプロイされた Amazon Simple Storage Service (Amazon S3) バケットに対してテストを実施する際、以下のように InSpec で利用されている Ruby でテスト内容を記述することができます。

describe aws_s3_bucket(bucket_name: 'inspec_demo_bucket') do   
  it { should exist }
  it { should have_versioning_enabled }
  it { should have_secure_transport_enabled }
  it { should have_access_logging_enabled }
  it { should_not be_public }
end

リファレンスアーキテクチャ

このソリューションでは、スクリプトのバージョン管理から、コンプライアンス監視のためのプロトコル生成とダッシュボード作成まで、エンドツーエンドで IQ を自動化することができます。

Figure 1: Reference architecture for automated IQ process using InSpec

図 1 ： InSpec を利用した自動 IQ プロセスリファレンスアーキテクチャ

これ以降の手順では、自動化ワークフローについて説明し、この自動化のための AWS サービスとプロセスを重点的に説明します。自動化された 8 つのステップのトリガーとなるプロセスには、大きく分けて 3 つのカテゴリがあります。

CI/CD ：バージョン管理、コードのビルド、インフラストラクチャのデプロイ、インテグレーションおよび InSpec を含むテスト実施です。これらを実現、管理するための AWS CodePipeline を利用します。
IQ ：これはデプロイ後の手順です。プロセスを実行してリソースを検証し、 IQ レポートを生成します。
継続的なコンプライアンス準拠：ベースラインからの変更についてリソースの属性を監視します。ダッシュボードには、展開されたリソースと、予想とは異なるリソースへのアラートが表示されます。

では、エンドツーエンドの IQ 自動化ソリューションの各ステップについてそれぞれみていきましょう。

Step1 ：バージョン管理とトリガーのための AWS CodeCommit

ソースコードおよびスクリプトは AWS CodeCommit を利用してバージョン管理します。リポジトリには、インフラストラクチャリソース構築のためのスクリプトの他に、 IQ レポート生成のための各種ソースコードも含まれます。操作者の権限を適切に制御、管理するためには、適切なリポジトリのアクセス制御を定義する必要があるます。是非ユーザーおよび役割に対して適切な権限管理を行なっていることを確認するためのドキュメントである CodeCommit Identity and Access Management をご参照ください。

Step2 ： AWS CodeBuild を利用したビルドトリガー (Infrastructure Installation/Deployment)

AWS CodeBuild (CodeBuild) はリポジトリに変更があれば実行されます。 CodeBuild は、 IaC スクリプトとして定義されている一連のタスクを実行します。タスクには AWS リソースの構築や IQ リソースのデプロイ、またテストも含みます。

Step3 ： InSpec の実行

CodeBuild で実行される InSpec スクリプトでは、デプロイされたリソースに対し設計通りに構築されているかどうかを検証します。 InSpec プロファイルとしていくつかの属性を記述した inspec.yml ファイルのサンプルを以下に記載しています。

name: my-profile 
title: My own AWS profile 
version: 0.1.0 
inspec_version: '>= 4.6.9' 
depends:
  - name: inspec-aws     
    url: https://github.com/inspec/inspec-aws/archive/x.tar.gz
supports:
  - platform: aws

Chef InSpec では、テスト結果を 1 つまたは複数のレポーターに出力することができます。レポーターとは Chef InSpec 監査の実行結果をフォーマットして配信する機能です。レポートは様々なフォーマットで生成することができます。

JSON
YAML
html
and many more

この例として、以下のコマンドラインでは JSON 形式でレポーター出力を生成します。

$inspec exec example_profile --reporter cli json:/tmp/output.json

InSpec でのテスト結果が記述された JSON ファイルは、 Amazon S3 に出力され保管されます。

Step4 ： IQ 自動化に向けた AWS CodeBuild トリガー

InSpec の評価テストが完了すると、テスト結果について確認します。もしテスト結果の中で想定している状態と実際の設定に異なる項目があれば、インフラストラクチャの変更はロールバックされます。問題なければ CodeBuild は IQ プロセスを起動します。

以下は InSpec テストが正常に完了した際の出力例です。

Finished in 0.08943 seconds (files took 6.92 seconds to load)
16 examples, 0 failures

Step5 ： IQ レポート生成

このステップでは 2 つの AWS Lambda(Lambda) で構成された AWS Step Function を利用します。この 2 つの Lambda は Fetch Data 関数と Generate PDF 関数です。 Fetch Data 関数の目的は、 Amazon S3 に出力されている複数の InSpec 実行結果を 1 つの JSON ファイルに統合することです。統合された JSON ファイルは後続の Lambda 関数のインプットとなります。 Generate PDF 関数は、データの集約、フォーマット、およびレポートの生成を行います。 2 つの Lambda 関数の出力は、トレーサビリティと監査の目的で、異なる Amazon S3 バケットに保存されます。

全ての IQ レポート作成で素早くデータを抽出できるように、処理パイプラインでのデータは以下のような構造で保管されます。

Amazon S3 raw data bucket: 複数の InSpec 実行結果を統合した JSON ファイルが保管されるバケット。 Generate PDF 関数のインプットとなる生データが保管されます。
Amazon S3 report bucket: IQ 結果を出力するバケット。
DynamoDB table: 各処理のメタデータを管理するためのテーブル。テーブルには実行 ID やタイムスタンプ、生データの Amazon S3 パス、 IQ レポートが出力された Amazon S3 パスといった重要な項目が格納される。このテーブルによって、全てのバージョンの IQ レポートのクエリと取得が簡単になります。

DynamoDB table

Step6 ： IQ 完了通知

AWS Step Function がの実行が完了すると Amazon Simple Notification System (Amazon SNS) による通知が送信されます。通知はグループまたは個人への電子メールやテキストメッセージ、 AWS SNS がサポートしている他のプロトコルなどさまざまな形式で行うことができます。通知には次の 2 つのタイプがあります。

レポート生成完了通知：正常に IQ レポートが生成されたことをEメールにて通知します。
異常通知：エラーが発生した場合や例外処理がうまく処理されなかった場合にエラーが通知されます。この通知には Amazon CloudWatch Logs のログストリーム ID の Link などが記載されています。

Amazon SNS による通知の送信先情報を、 IaC でデプロイする Lambda の環境変数に設定しておくと良いでしょう。

Step7 ：ダッシュボード生成のための InSpec データエンジニアリングパイプライン

InSpec テスト結果は、IQ レポートの生成の他にも継続的なコンプライアンスの監視と追跡をサポートするために使用されます。データをダッシュボードに使用する前に、データを前処理して変換する必要があります。データエンジニアリングパイプラインには、データ変換、ラベリング、メトリック計算が含まれます。

Step8 ：継続的なコンプライアンス準拠のためのダッシュボード

完全に統合された IaC ソリューションであるため、インフラストラクチャのデプロイスクリプトに変更を加えると、テストスクリプトのデプロイと実行がトリガーされます。継続的コンプライアンス準拠のためのダッシュボードは、デプロイされたリソースとそれに対応するステータスの概要を提供します。

Figure 2: Reference dashboard to display compliance metrics by resources

図 2 ：リソースごとのコンプライアンスメトリックを表示するための参照ダッシュボード

自動化された Infrastructure Installation Qualification の利点

インフラストラクチュア IQ プロセスを自動化することによる利点はいくつもあります。まず大きな利点の一つはインフラストラクチャのデプロイを効率的に実施できるということです。一度 IQ 自動化ソリューションがデプロイされると、変更管理のサイクルに要す時間が大幅に短縮され、継続的なコンプライアンス準拠が保証されることになります。インフラストラクチュアのIQ 自動化ソリューションによって、開発、デプロイ、テストのプロセスの自動化に繋がり、一貫性を向上することができます。これに加えて、インフラストラクチャ IQ プロセスの自動化による利点をいくつか記載します。

コストの削減：ドキュメント作成にかかる労力を削減することができるため、インフラストラクチャのコンプライアンスを管理するコストを削減することができます。
バーション管理：インフラストラクチャ環境をIaCスクリプトのバージョン管理でコントロールすることができ、障害が発生した際には安定した前のバージョンにロールバックすることができます。
IaC ツールの選択：ここに示したリファレンスアーキテクチャは IaC ツールとして何を選択するかに依存します。 AWS 環境の構築には、様々な IaC ツールの選択肢があります。
再現性：複製、再度デプロイ、再テストが可能なインフラストラクチャを実現することができます。このソリューションではマスターアカウント、組織単位、またはアプリごとに一元管理することができます。
拡張性：サーバレスアーキテクチャであり、大半のサービスの認定に向けたテストに利用することが可能です。

前提条件

ここで紹介した IQ の完全自動化にむけたソリューションには、いくつかの前提条件があります。セキュリティの観点から本番環境の AWS アカウントではマネジメントコンソールを利用した操作は読み取り専用に設定すべきです。また、本番環境のデプロイは全て変更管理とプルリクエストの承認時に実行される IaC パイプラインを通して実施したほうが良いでしょう。

まとめ

このブログでは、インフラストラクチャ IQ プロセスを自動化するリファレンスアーキテクチャについて説明しました。上記のステップを実行することでインフラストラクチャのデプロイから、認定テストの実行、 IQ レポートの作成、それから継続的なコンプライアンス準拠までエンドツーエンドでのプロセスをカバーすることができます。継続的な適格性および検証済みの状態を維持する作業は、自動化によって簡素化されます。手作業と比較して、 IQ レポートの作成にかかる時間を自動化によって少なくとも60％は短縮することができます。自動化されたインフラストラクチャ IQ プロセスによって、 AWS が提供するインフラストラクチャのアジリティとその他の特徴を最大限引き出すことができます。
AWS CloudFormation についてより詳細になりたい場合は、こちらのドキュメントをご参照いただき、テンプレート構造の詳細については AWS CloudFormation Template Anatomy をご確認いただければと思います。また Chef InSpec が対応している AWS リソースについてもご確認いただき、詳細な情報については Chef InSpec のドキュメントをご確認ください。

著者について

Iftikhar Khan

ヘルスケアおよびライフサイエンスのクラウドアプリケーション開発者であり、設計からさまざまなテクノロジーを使用した展開まで、 11 年以上にわたりエンドツーエンドのソフトウェア開発をリードしてきました。ヘルスケアおよびライフサイエンス業界、特に規制およびコンプライアンスの分野で顧客向けのソリューションの開発を支援しており、クラウドネイティブアプリケーション、 Devops カルチャー、マイクロサービスの移行と最新化を専門としています。

Firasat Ansari

バイオ医薬品および製造業に 17 年以上従事しています。近年、 AWS を使用し、規制された環境に対する自動化ソリューションの開発に注力しています。

Nelson Key

ヘルスケアおよびライフサイエンス業界で 14 年以上の経験があり、特にバイオ医薬品業界でアプリケーション開発と自動化をリードすることに重点を置いています。 AWS に参加する前は、ネルソンはエンタープライズプラットフォームとクロスファンクショナルアプリケーションの開発を主導し、アムジェンのバリューチェーン全体で高度な分析と洞察を提供していました。彼の専門分野は、クラウドコンピューティングにおける規制とコンプライアンスの自動化です。ネルソンは、南カリフォルニア大学でコンピューターサイエンスの修士号を取得しています。

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

Amazon Web Services ブログ