【PIC/Sデータ・インテグリティ関連ガイドラインドラフトについて(３)】ASTROM通信 225号

まだまだ残暑が厳しい毎日ですが、いかがお過ごしでいらっしゃいますか？

今回も前回に引き続き、2021年7月1日に発効したPIC/Sガイドライン、「GMP/GDP環境でのデータ管理とインテグリティに関する適正管理基準（PI 041-1」について見ていきたいと思います。

出典
https://picscheme.org/docview/4234

PIC/S　GUIDANCE
GOOD PRACTICES FOR DATA MANAGEMENT AND INTEGRITY IN REGULATED GMP/GDP ENVIRONMENTS　　

９章　コンピュータ化システムに関するデータ・インテグリティの留意事項

9.1　医薬品品質システムの体制とコンピュータ化システムの管理

9.1.1 多種多様なコンピュータ化システムが多数の操作を手助けするために会社で
　　　使用されている。シンプルなスタンドアロンから、広く統合されて複雑なもの
　　　まであり、それらの多くは、製造される製品の品質に影響を与える。全ての
　　　コンピュータ化システムを評価して管理し、GMP及びGDPの要件に従って運営
　　　することは、法律で規制された組織の責任である。
9.1.2 組織は、利用されるコンピュータ化システムの性質と範囲を完全に承知している
　　 べきであり、各システムの使用目的と機能、改ざんの影響を受けやすい
　　 データ・インテグリティのリスクまたは脆弱性の記述のアセスメントが行われて
　　 いるべきである。製品品質に関わるコンピュータ化システム及び関連するデータ
　　 の重要性の判断に重点が置かれるべきである。
9.1.3 製品品質に影響を与える可能性のある全てのコンピュータ化システムは、偶然
      または意図的な改ざん、または、データの品質やインテグリティに影響を与えうる
　　 変更やその他の活動からシステムが保護されていることを保証するために設計
　　 された医薬品品質システムのもとで効果的に管理されるべきである。
9.1.4 規制対象のユーザはシステムのベンダがGMP/GDPとデータ・インテグリティの
　　 要件の適切な理解を持つことと、新しいシステムが効果的なデータ・マネジメント
　　 を保証するための適切な管理を含むことを保証しなければいけない。
　　 レガシー・システムも、同じ基本要件を満たすことが期待されるが、完全な
　　 要件遵守には、管理上の手順またはセキュリティを補うハードウエア/ソフトウエア
　　 のような追加の管理の使用を必要かもしれない。
9.1.5 規制対象のユーザは、コンピュータ化システムで生成されるデータの範囲と性質を
　　 完全に理解すべきである、データのリスクとデータ（メタデータを含む）の重要性
　　 を判断し、生成されたデータを管理するために必要とされるその後の管理に、
　　 リスクベースドアプローチがとられるべきである。例えば：
9.1.5.1 ローデータに対処する際、製造のイベントや分析を復元するために、ローデータ
　　　 の完全な保存と保持が標準的に必要とされなければならない。
9.1.5.2 メタデータに対処する際、一部のメタデータはイベント（例：ユーザの識別、
　　　 時間、重要な工程のパラメータ、測定の単位）の復元に重要であり、“関連する
　　　 メタデータ”として、完全に保存され管理されるべきである。しかし、システムの
　　　 エラーログやシステムチェックのような重要でないメタデータは、
　　　 リスクマネジメントの使用が正当である根拠がある場合、全ての保存と管理は
　　　 必要でないかもしれない。
9.1.6 データの脆弱性やリスクを判断するとき、コンピュータ化システムの
　　 ビジネスプロセス内での使用の背景が考慮されることが重要である。例えば、
　　 統合されたコンピュータのインタフェースを利用した分析手段により生成された
　　 結果のインテグリティは、サンプルの準備、システムへのサンプルの重さの入力、
　　 データを生成するためのシステムの利用、データを使用した最終結果の処理・記録
　　 の影響を受ける。データフローマップの作成とアセスメントは、特に連携した
　　 コンピュータ化システムのリスクと脆弱性の理解に役立つだろう。
9.1.7 特に今のデータ管理の要件を満たすために設計されている現代的なシステムを
　　 利用するより脆弱なシステム及び/またはソフトウエアには、固有のデータ・インテ
　　 グリティの管理が組み入れられることが考慮されるべきである。脆弱性を持つ
　　 システムの例：マニュアルの記録システム、時代遅れのセキュリティ手段を持つ
　　 より古い電子システム、ネットワーク化されていない電子システム、ネットワーク
　　 の追加のセキュリティ保護（例：ファイアウォールを使用し、不法な侵入の検知と
　　 予防をするシステム）を必要とする電子システム
9.1.8 コンピュータ化システムの査察において、査察官はアセスメント中、その会社の
　　 助言を利用することが推奨される。アクセスと指示を円滑に進めるために、会社の
　　 担当者に質問をし、指示をすることは、システムの査察を助けることができる。
9.1.9 このガイドラインは、コンピュータ化システムを背景としたデータ・インテグリティ
　　 に関する留意事項を提供することを目的としている。コンピュータ化システムに
　　 関する適正な管理基準に関する更なるガイドラインは、
　　 PIC/Sの、規制された“GxP”環境におけるコンピュータ化システムの適正な
　　 管理基準(PI 011)にも記載されているかもしれない。
9.1.10 この原則は、コンピュータ化システムの提供が外部委託されている状況でも同様
　　 に適用する。その場合、外部委託されたサービスが、GMP/GDPの要件に従って管理
　　 両組織に理解され効果的に実施されていることを保証するための責任は、規制を
　　 受ける企業にある。

9.2　コンピュータ化システムの適格性評価とバリデーション
9.2.1 コンピュータ化システムの適格性評価とバリデーションは、関連するGMP/GDPの
      ガイドラインに従って実施されるべきである：以下の表に、コンピュータ化システム
　　 の適正なデータ・ガバナンスの基準の保証についての特別な期待に関する説明を
　　 提供している。
9.2.2 バリデーションだけでは、生成された記録が適切に保護されていることを必ずしも
　　 保証しないし、バリデートされたシステムは、偶然または悪意のある方法による
　　 喪失や変更に対して脆弱な可能性がある。従って、バリデーションは、適切な管理上
　　 のまたは物理的なコントロールや、ユーザの訓練や教育により補われるべきである。

9.3　バリデーションとメンテナンス
＜システムのバリデーションとメンテナンス＞

■１－期待

規制を受ける会社は、データ・マネジメントとインテグリティに関する要件がシステム調達の最初の段階と、システムとデータのライフサイクルを通じて考慮されていることを保証するために、適切な管理を文書化して実装しなければならない。規制を受けるユーザについては、機能仕様書（FS）、ユーザ要求仕様書（URS）は、データ・マネジメントとインテグリティの要件に適切に対処しなければならない。
システムがデータ・インテグリティのコントロールに関して購入前に適切に評価されることを保証するために、GMP/GDPの重要な装置の購入に特別な注意が払わなければならない。
使用中のレガシー・システムは、存在しているシステムの機器構成や機能が、適正なデータ・マネジメントとインテグリティの管理基準に従って、データの適切な管理が可能なのかどうかを判断するために評価されるべきである。これらのシステムの機能や設計が適切な管理レベルを提供しない場合、追加の管理が検討され実装されるべきである。

■１－期待を満たさない場合の潜在的なリスク/チェック項目

• DI(データ・インテグリティ）　の要件の不十分な検討により、求められるデータ・マネジメントとインテグリティの期待を満たす基本機能を含まないソフトウエアシステムを購入することになるかもしれない。
• 査察官は、新しいシステムの実装が、DIの原則を適切に考慮した手順に従っていることを確認しなければならない。
• いくつかのレガシー・システムは検知の可能性の低いデータの改ざんの余地があり、データ・マネジメントに関する適切な管理を含まないかもしれない。
• 存在するシステムのアセスメントは、入手可能であり、全ての脆弱性に関する概説と、データ・インテグリティを保証するために実装された全ての追加の管理のリストを提供しなければならない。追加の管理はバリデートされていなければならず、以下のことを含んでいてもよい。
  • ユーザの特権をコントロールするための管理を含まないソフトウエアの場合、オペレーティング・システムの機能の使用
    （例：Windowsのアクティブ・ディレクトリ・グループ）
  • ソフトウエアでデータファイルの修正/削除の管理ができない場合、ファイルの修正/削除を防ぐためのファイル/フォルダに対して許可をする設定操作システム
  • 生成されたデータの管理をするためのハイブリッドまたはマニュアルの仕組みの実装

――――――――――――――――――――――――――――――――――――――――

■２－期待

規制を受けるユーザは、使用中の全てのコンピュータ化システムの台帳を持っていなければならない。このリストには以下のことに関する内容を含まなければならない。

• 各コンピュータ化システムの名前、設置場所と主要な機能
• 機能とシステム及び関連するデータの重要性のアセスメント
  （例：GMP/GDPへの直接の影響あり、非直接の影響あり、何もなし）
• 各システムの現在のバリデーションの状態と、存在するバリデーション文書の参照

特に、データ・インテグリティを保証するために必要な管理の評価を行い、各システムのリスクアセスメントが行われているべきである。データ・インテグリティに関する管理のバリデーションのレベルと範囲はシステム及び処理の重要性と、製品品質へのリスクの可能性に基づいて判断されるべきである。例：ロットのリリースデータを生成または管理する処理やシステムは、一般的に、重要性の低いデータや処理を管理するシステムより大きな管理が要求される。
より高いリスクの可能性を持つこれらのシステムについて、災害、誤動作、または、システムが動作不能になることに関する考慮もされるべきである。
アセスメントは、システムの重要な構成設定の不注意もしくは無断の変更や、データの改ざんに関する脆弱性もレビュすべきである。全ての管理は、文書化され、有効性が検証されていなければならない。

■２－期待を満たさない場合の潜在的なリスク/チェック項目

• 全てのコンピュータ化システムに関して適切な可視性を持たない会社はシステムの重大性を見落とし、データのライフサイクルを通じて脆弱性を生むかもしれない。
• システム台帳は、これらのシステムに対するすべての変更や改良が管理されることを保証し、全てのシステムが明確に連携することに役立つ。
• リスクアセスメントが重要な処理装置やデータ収集システムに関して実施されていることを確認せよ。システムの影響の徹底的なアセスメントの欠如は、適切なバリデーションとシステムの管理の欠如につながるだろう。レビュするための重要なシステムの例は、以下の通りである。
  •  製品及び原材料の購入やステイタスの管理をするシステム
  • 重要な製造工程の管理とデータ収集をするシステム
  • ロットの品質を判断するために使用される、データを生成し、保存し、処理するシステム
  • ロットの加工や包装の記録に含まれるデータを生成するシステム
  • 製品の出荷判定に関する判断の過程で使用されるシステム

――――――――――――――――――――――――――――――――――――――――

■３－期待

各コンピュータ化システムのバリデーション・サマリ・レポート（Annex15の要件に従って書かれ承認されたもの）が整えられ、少なくとも下記の内容が記述（もしくは参照）されていなければならない。

• 重要なシステムの構成設定の詳細と、構成設定へのアクセス制限に関する管理と、全ての変更（変更管理）
• ユーザの名前とその役割を明記した、現在許可されている全ての通常のユーザと管理ユーザのリスト
• 監査証跡とシステムログのレビュの頻度
• 下記の手順
  • 新しいシステムユーザの作成
  • 存在しているユーザの修正または権限の変更の手順
  • 各システムのパスワードの組み合わせ/フォーマットの定義
  • ユーザのレビュと削除の手順
  • バックアップの手順と頻度
  • 災害復旧
  • アーカイブしたデータのアクセスと読み取りの手順を含む、データのアーカイブ
    （手順と責任）
  • データ保管の認められた場所
• レポートは、製造工程または分析作業を復元することを可能にするフォームで関連メタデータと共にオリジナルデータがいかに保管されているかを説明しなければならない。

バリデーション・サマリ・レポートには必要性が書かれていないが、既存のシステムについて、上記の要件を明記した文書が利用できなければならない。これらの文書は、規制を受けるユーザにより、必要に応じて維持・更新されなければならない。

■３－期待を満たさない場合の潜在的なリスク/チェック項目

• バリデーションのシステムとレポートが以下のGMP/GDP要件とALCOAの原則を考慮したインテグリティの要件に対応していることをチェックせよ。
• システムの構成設定と職務の分離（例：データを生成する権限は、データを検証する権限と独立すべきである）がバリデーションの前に定義され、試験中効果的に検証されているべきである。
• システムへの改良や変更が制限され、変更管理マネジメントの対象になっていることを保証するためのシステムのアクセスに関する手順をチェックせよ。
• システムの管理者アクセスがオーソライズド・パーソンに限定されていて、日常の作業で使用されていないことを保証せよ。
  保証するために、その手順をチェックせよ。ユーザのアクセスログと特権レベルをチェックせよ。権限のないユーザのシステムへのアクセスがなく、アクセス・アカウントは最新化されていなければならない。
• ユーザが監査証跡機能を修正することや、予め設定されたデータファイルが保存されるディレクトリ・パスを変更することを防ぐための制限もあるべきである。

――――――――――――――――――――――――――――――――――――――――

■４－期待

会社は、コンピュータ化システムのバリデーションに関する具体的な方針と要求事項とシステムや関連データのインテグリティの要求事項を含むバリデーション・マスタ・プランを整えなければいけない。コンピュータ化システムのバリデーションの範囲は、リスクに基づいて判断されなければならない。
コンピュータ化システムバリデーションの要求事項の評価に関する更なるガイドラインは、PI 011にも記載されているだろう。
システムが日常的な使用に移行する前に、許容範囲に適合することを確認するために決められたテストが実施されなければならない。
コンピュータ化システムの予測的バリデーションが実施されることが期待される。適切なバリデーションデータが、既に使用中のシステムにおいて利用可能でなければならない。
コンピュータシステムバリデーションは、必要に応じて、GMP Annex15のURS（ユーザ要求仕様書）、DQ（設計時適格性評価）、FAT（工場出荷試験）、SAT（現地受入試験）、IQ（据付時適格性評価）、OQ（運転時適格性評価）、PQ（性能適格性評価）の内容に従って設計されなければならない。
適格性評価の試験のアプローチは、バリデーション中、具体的なシステムに関して調整され、規制を受けるユーザによって正当である根拠が示されなければならない。適格性評価には、DQ（設計時適格性評価）、IQ（据付時適格性評価）、OQ（運転時適格性評価）、PQ（性能適格性評価）を含む。特に、データの品質やインテグリティにリスクがある分野の試験をするために、固有の試験が計画されるべきである。
会社は、コンピュータ化システムがその使用目的に関して適格性が評価されていることを保証すべきである。従って、会社は、ベンダの適格性評価されたパッケージだけを信頼すべきではない；バリデーション活動は、通常の使用と意図した使用が織り込まれた作業中にデータのインテグリティが維持されることを保証するため、特定の試験を含むべきである。
試験の数は、リスクアセスメントにより導き出され、少なくとも重要な機能が特定されて試験されるべきである。例えば、基本的なアルゴリズムまたはロジックの組み合わせに基づくPLCやシステムの場合は、機能的試験が、コンピュータ化システムの信頼性を適切に保証するだろう。重要で、かつ/または、より複雑なシステムは、IQ、OQ,PQの段階において詳細の検証試験が必要とされる。

■４－期待を満たさない場合の潜在的なリスク/チェック項目

• バリデーション文書がデータ・インテグリティに関する固有の条項を含んでいることを確認せよ；バリデーション・レポートは、データ・インテグリティの原則に対応し、設計と試験を通じて適切な管理が整っていることを示すべきである。
• バリデートされていないシステムは、ユーザのアクセスやシステム設定がデータの修正を許す可能性があるので、データ・インテグリティに関して重大な脆弱性が存在するかもしれない。
• エンド・ユーザの試験は、ソフトウエアがベンダの要件を満たすだけでなく、その意図した使用に合っていることを示すために設計されたテストスクリプトを含んでいることをチェックせよ。

――――――――――――――――――――――――――――――――――――――――

■５－期待

定期的なシステム評価
コンピュータ化システムは、データ・インテグリティの管理を考慮した継続的なコンプライアンス状態にあることを保証するために定期的に評価されるべきである。
評価は、逸脱、変更（変更の全ての蓄積された影響を含む）、アップグレードの履歴、性能とメンテナンスを含むべきである。また、これらの変更がデータ・マネジメントとインテグリティの管理に有害な影響を与えなかったかを評価すべきである。
再バリデーションの頻度は、前回のレビュからシステムに対して実施された変更の蓄積された影響を考慮し、コンピュータ化システムの重要性によるリスクアセスメントに基づくべきである。実施されたアセスメントは文書化されるべきである。

■５－期待を満たさない場合の潜在的なリスク/チェック項目

• バリデーション・スケジュールの中に、コンピュータ化システムの再バリデーションのレビュの概要が述べられていることをチェックせよ。
• システムが、特にデータ・インテグリティに関する全ての潜在的な脆弱性を考慮し、定期的なレビュの対象になっていることを確認せよ。
• 既存のソフトウエア/ハードウエアの欠点などの、確認された全ての問題がタイムリーに対処され、確認された全てのリスクを管理するために是正処置・予防処置や暫定的な管理が利用可能で実施されるべきである。

――――――――――――――――――――――――――――――――――――――――

■６－期待

オペレーティング・システムとネットワーク部品(ハードウエアを含む)はベンダの提案に従ってタイムリーに更新され、古いプラットフォームから新しいプラットフォームへのアプリケーションの移行は、システムにより生成されたデータのマネジメントとインテグリティに影響を与えうることになるプラットフォームがサポートされない状態になる前に計画され、実行されるべきである。
オペレーティング・システムとネットワーク部品のセキュリティ・パッチは、データの安全性を維持するために、ベンダの提案に従って、管理されたタイムリーな方法で適用されるべきである。セキュリティ・パッチの適用は、変更管理の原則に従って実施されるべきである。
サポートされていないオペレーティング・システムが維持される場合、即ち、古いオペレーティング・システムについて、ベンダもしくはサポートされたバージョンのセキュリティのパッチがあてられる期間が切れた後は、システム（サーバ）は、可能な限り、その他のネットワークから隔離されるべきである。残ったインタフェースと他の装置へ/からのデータの転送は、サポートされていないオペレーティング・システムにより引き起こされる脆弱性の発生を防ぐために慎重に設計され、設定され、適格性を評価されなければならない。サポートがされていなシステムは、固有の脆弱性のリスクにより、リモートアクセスは慎重に評価されるべきである。

■６－期待を満たさない場合の潜在的なリスク/チェック項目

• システムのアップデートは、管理されたタイムリーな方法で実施されていることを確認せよ。古いシステムは、適切なデータ・インテグリティの管理が統一されていること、または、（統一した管理が不可能な場合は）適切な管理が実装されていて効果的であることが十分にレビュされるべきである。

9.4　データ転送
＜データ転送と移行＞

■１－期待

インタフェースは、正しく完全なデータの転送を保証するために、バリデーション中に評価され対処されるべきである。
インタフェースは、データ・インテグリティのリスクを最小化するために、正しい安全なデータの入力と処理に関する適切な組み込みのチェックを含むべきである。検証方法は、下記の使用を含むとよい。

• 安全な転送
• 暗号化
• チェック・サム（※データ通信におけるエラー検出方法の一つ）

可能であれば、システム間のインタフェースは、GMP/GQPデータの転送の自動化を含めて設計され、検証されるべきである。

■１－期待を満たさない場合の潜在的なリスク/チェック項目

• コンピュータ化システム間のインタフェースは、転送中に、データが気づかずに失われたり、間違って修正されたり書き換えられたりするリスクをもたらす。
• データが安全な場所/データベースに直接転送され、ローカル・ドライブ（変更される可能性がある場所）から簡単にコピーされないことを保証せよ。
• 最終的なデータ保管場所またはデータ処理場所に転送される前のローカルなコンピュータ化システム（例：機器のコンピュータ）の一時的なデータ保管場所は、データが消されたり、改ざんされたりする可能性を作る。これは、スタンドアロン（ネットワークでつながっていない）システムの固有のリスクである。最初にデータが保管された環境は適切なデータ・インテグリティの管理が整っていることを保証せよ。
• うまく設計され、適格性評価がされている自動データ転送は、人により実施されるいかなる手動データ転送より信頼できる。

――――――――――――――――――――――――――――――――――――――――

■２－期待

システムのソフトウエア(オペレーティングシステムを含む)がインストールもしくはアップデートされる場合、ユーザは、アーカイブされたデータが新しいソフトウエアで読めることを保証すべきである。これは、必要に応じて、存在しているアーカイブされたデータの新しいフォーマットへの変換が求められるかもしれない。
データが新しいソフトウエアの新しいデータ・フォーマットに変換が出来ない場合、古いソフトウエアは、例えば１つのコンピュータ内にインストールされるか、他の技術的解決策により維持され、査察時にアーカイブされたデータを読むためにバックアップメディアとして利用可能でなければならない。

■２－期待を満たさない場合の潜在的なリスク/チェック項目

• データのライフサイクルを通じて、データはそのもともとの形式で読めることが重要である。従って、ユーザは、データの可読性を維持しなければならず、廃止されたソフトウエアへのアクセスを保持することが求められるかもしれない。
• 1つのシステムから別のシステムへのデータの移行は、管理された方法で、文書化手順に従って実施され、データの完全な移行の適切な検証を含まなければいけない。

――――――――――――――――――――――――――――――――――――――――

■３－期待

レガシー・システムのソフトウエアがもはやサポートされない場合、データのアクセス可能性 (特定の保管要件によりできるだけ長く))のために、ソフトウエアの維持に関して考慮されるべきである。これは仮想環境にソフトウエアを保持することで達成されるかもしれない。
可能な限り“真正なコピー”の属性をもった他のファイルフォーマットへの移行は、年数が経過するレガシー・データに必要になるかもしれない。
オリジナルのデータの機能完全に備えた移行が技術的に可能でない場合、代替手段が、リスクとデータの重要性に基づいて時間と共に評価されるべきである。移行ファイルフォーマットは、長期間のアクセス可能性 対 動的データの機能(例：データの問い合わせ、トレンド、再加工)の減少の可能性を考慮して選択されるべきである。リスクアセスメントは、システムの重要な構成設定へのうっかりした、または、許可されない変更や、データの改竄に対する脆弱性のレビュもすべきである。リスクを軽減するための全ての管理は文書化され、それらの有効性が検証されるべきである。アクセス可能性を維持するために、いくつかの属性・動的データの機能を失うファイルフォーマットへの移行を必要とするかもしれないことは受け入れられる。

■３－期待を満たさない場合の潜在的なリスク/チェック項目

• ソフトウエアが仮想環境に保持される場合、ソフトウエアを管理するための適切な手段（例：バリデーション状態、許可された職員によるアクセス管理）が整っていることをチェックせよ。全ての管理は文書化され、それらの有効性が検証されるべきである。

9.5　コンピュータ化システムのシステム・セキュリティ
＜システム・セキュリティ＞

■１－期待

ユーザのアクセス管理は、データへの権限のないアクセスや変更や削除を禁止するために設定され、強化されなければならない。セキュリティ管理の範囲は、コンピュータ化システムの重要性による。例えば：

• 個々のログインIDとパスワードは、電子システムにアクセスし利用する必要のある全てのスタッフに設定され、与えられなければならない。共有されたログイン認証情報は、活動を行った個々のトレーサビリティのために、許されない。この理由から、経済的な節約のためであっても、共有パスワードは禁止されるべきである。
  ログイン・プロファイル、構成設定、パスワードのフォーマットが明確に定義され、意図した通りに機能することを保証するために、電子システムのバリデーション中に検証されるべきである。
• コンピュータ化された記録に対するデータの入力と変更は、許可された職員によってのみ実施されるべきである。会社は、使用中の各電子システムについて、アクセスを許可された個人と、彼らのアクセス権限のリストを保持すべきである。
• システムが効果的に保護されていることを保証するために、パスワードのフォーマットと使用に関する適切な管理が行われるべきである。
• はじめに許可されたシステムのアクセスに基づき、システムは、通常のパスワードのルールに従い、ユーザが新しいパスワードを作ることを許可しなければならない。
• システムは、ユーザのさまざまなアクセスの役割（レベル）をサポートし、役割の割り当ては、最低限の特権付与のルール、すなわち、いかなるジョブの機能に対しても最低限必要なアクセスレベルを付与すること、に従うべきである。最低限として、シンプルなシステムは、通常ユーザと管理ユーザを持つべきだが、より複雑なシステムは、通常は、アクセス管理を効果的にサポートするためにユーザにより多くのレベル(例：階層)が必要になるだろう。
• GMP/GQPの重要なアプリケーションを運営するために、コンピュータシステムやインフラへの管理者のアクセス権限を許可することは、厳しく管理されるべきである。
  管理者のアクセス権限は、システムの通常のユーザに与えられるべきではない。
  （職務の分離）
• 通常のユーザは、コンピュータシステムの重要な局面へのアクセス権限を持つべきでない。（例：システム・クロック、ファイルの削除機能等）
• システムは、システムに実際にアクセスしたユーザの名前と役割を含むリストを作ることができるべきである。そのリストは、定期的なユーザのレビュ中に用いられるべきである。ユーザのリストは、名前または特定の個人を識別できるユニークな識別子を含むべきである。このリストは、定期的なユーザのレビュ中に使用されるべきである。
• システムは、下記の情報を含んだ、ログインの試みの成功と失敗のリストを作ることができるべきである。
  •  ユーザの名前
  •  ユーザの役割
  •  ログインを試みたローカル時間、または、ローカル時間がトレースできる日時
  • セッション(交信)の長さ（ログイン成功時）
• ユーザのアクセス管理は、役割の厳格な分離を確実に行うべきである。（すなわち、通常の業務を行うシステムの全ユーザは、通常のアクセス権限のみを持つべきである。)
  普通は、高いアクセス権限を持ったユーザ（例：管理者）は、システムで通常業務を実施すべきでない。
• システム管理者は、通常、ユーザの実施する業務と独立し、生成されたデータに関与や関心を持ってはいけないし、電子システムを利用できてはいけない。例えば、QCの管理者やマネージャは、試験室の電子システム（例：HPLC、GC、UV－Vis）のシステム管理者に任命されるべきではない。通常は、品質や製造の組織の外部の人間（例：情報技術の管理者）がシステム管理者の役目を果たし、高度な許可レベルを持つべきである。
• より小さな組織の場合、品質部門や製造部門で指名された人間がシステム管理者としてアクセス権限を持つことは許容してもよい。しかし、これらの場合、管理者のアクセスは、日常作業の実施に用いられるべきではなく、ユーザは、第二の日常作業の実施用の制限されたアクセス権限を持つべきである。これらの場合、管理者の実施した全ての活動は、記録され、品質システム内で承認されるべきである。
• 新しいユーザ、新しいユーザの権限に関する全ての要求は、適切な職員（例：ラインのマネージャ、システムオーナ）に許可され、標準手順に従ってトレース可能な方法でシステム管理者に送付されなければならない。
• GMP/GQPの重要なデータや作業にアクセスするコンピュータシステムは、事前に定義した時間よりも長い間不応のユーザを、アプリケーションまたはオペレーション・システムレベルでログアウトする非活動ログアウト機能を持つべきである。その時間は、通常は、長くするのではなく、システムへの権限のないアクセスを防ぐために短く設定されるべきである。非活動ログアウトの有効化に加え、システムは、再ログインのために通常の認証手順を要求すべきである。

■１－期待を満たさない場合の潜在的なリスク/チェック項目

• 会社が、使用中のコンピュータ化システムが安全で、意図的またはうっかりした変更から保護されていることを保証するためにあらゆる合理的なステップを踏んでいることをチェックせよ。
• 物理的かつ管理上保護されていないシステムは、データ・インテグリティの点で脆弱である。査察官は、コンピュータ化システムがバリデートされ、改ざんから保護された状態が保たれていることを保証する、システムのセキュリティを管理する検証された手順が存在することを確認すべきである。
• 個々のユーザログインIDが使用されていることを確認せよ。システムの構成設定が、個々のユーザのログインIDの使用を認めている場合、これらが使用されるべきである。
• 一部のコンピュータ化システムは、単一ユーザのログイン、または、限定された人数のユーザのログインのみをサポートしていることが認識されている。適切な代替のコンピュータ化システムが利用できない場合、サードパーティのソフトウエア、または、トレーサビリティ（バージョン管理と共に）を提供する紙ベースの方法による同等の管理が提供されてもよい。代替システムの適合性は、正当化され、文書化されなければならない。ハイブリッドシステムについては、さらなるデータレビュが求められることがありうる。
• 査察官は、システムが適切なパスワードのルールを強制し、強固なパスワードを要求することを保証するためにパスワードの方針が整っていることを確認すべきである。
  重要なデータを生成し処理するシステムには、より強固なパスワードを使用するための検討がなされるべきである。
• ユーザによって新しいパスワードが変更できず、管理者のみがパスワードを作れるシステムは、パスワードの信頼性が保持できないので、データ・インテグリティに合わない。
• ユーザのアクセスレベルが適切に定義され、文書化され、管理されていることをチェックせよ。ユーザの単一のアクセスレベルを使用し、この役割を全ユーザに割り当てることは、定義次第でアクセスレベルは管理者の権限になるので、容認できない。
• 許可された個人だけがシステムを使用でき、電子的に記録に署名し、操作を行い、入力または出力装置にアクセスし、記録を変更し、または手近で作業が行えることを保証するために、システムは管理者がチェックしていることを確認せよ。

――――――――――――――――――――――――――――――――――――――――

■２－期待

コンピュータ化システムは、偶然の変更や意図的な改ざんから保護されているべきである。会社は、最終的にデータ・インテグリティに影響を与えうるバリデートされた設定に対する許可のない変更を防ぐためにシステムとその設計を評価すべきである。
以下の考慮がされるべきである。

• コンピュータ化システムのハードウエアの物理的セキュリティ：
  • サーバの場所とアクセス制限
  •  PLCモジュールへのアクセス制限（例：点検用パネルの錠締め）
  •  コンピュータ、サーバ、メディアへの物理的なアクセスは、許可された個人に限定されるべきである。通常は、システムのユーザは、サーバやメディアに対するアクセス権限を持つべきでない。
• ローカルや外部の攻撃からのネットワークシステムの脆弱性
• リモートのネットワークの更新（例：ベンダによるネットワークシステムの自動更新）
• システムの設定、構成や重要データのセキュリティ
  システムの重要なデータ/操作パラメータへのアクセス権限は適切に制限され、設定/構成の変更は、権限を与えられた職員により変更マネジメント手順を通じて管理されていなければならない。
• システム時間は、接続するシステムの時計と同期され、全ての時計へのアクセスは権限を与えられた職員に限定されるべきである。
• 侵入の防止と検知のシステムを含む、適切なネットワークのセキュリティの手段が適用されるべきである。
• ファイアウォールは、重要なデータや作業を守るためにセットアップされていなければならない。ポートの開放(ファイアウォールのルール)は、可能な限り厳しくし、許可されたトラフィックのみを許可し、最低限の特権付与方針に基づくべきである。
  規制を受けるユーザは、ネットワークセキュリティの手段（例：潜在的なセキュリティの弱さを特定するためのITインフラのネットワークの脆弱性のスキャンの使用）の継続的な妥当性と効果の定期的なレビュを実施し、オペレーティング・システムが現在のセキュリティ手段を維持していることを保証しなければならない。

■２－期待を満たさない場合の潜在的なリスク/チェック項目

• ハードウエアとソフトウエアへのアクセスが適切に保護され、権限を与えられた職員 に限定されていることをチェックせよ。
• 適切な認証方法が実装されていることを確認せよ。これらの方法は、ユーザIDと パスワードを含んでいるか、他の方法でもよいが、認証が要求されなければならない。
  ユーザが確実に特定可能であることが必須である。
• インターネット経由で利用できる重要なデータを含むシステムのリモートの認証については、パスコード・トークンや生体認証の使用などの追加の認証技術が使用されていることを確認せよ。
• システムの重要な操作パラメータへのアクセスが適切に管理され、システムが、GMP/GQPの手順において、イベントやパラメータやの正しい順番を強制することを確認せよ。

――――――――――――――――――――――――――――――――――――――――

■３－期待

ネットワークの保護
ネットワークシステムのセキュリティは、データへの潜在的な脅威を検知し防ぐための適切な方法を含むべきである。
実装されるネットワークの保護のレベルは、データのリスクのアセスメントに基づくべきである。
ファイアウォールが、許可されないアクセスに使用されるべきであり、ファイアウォールのルールは、許可されたトラフィックのみ許可し、必要であれば制限をかけるように設定されていることを保証するために、定期的なレビュの対象とされるべきである。レビュは文書化されていなければならない。
ファイアウォールは、意図的な攻撃やマルウェアからデータやコンピュータ化システムを守るために、適切なウイルス保護または侵入の防止/検知システムと共に補完されなければならない。

■３－期待を満たさない場合の潜在的なリスク/チェック項目

• 不十分なネットワークのセキュリティは権限のないアクセスや誤用や修正によるシステムの脆弱性に関連したリスクをもたらす。
• ネットワークのアクセスを管理するための適切な方法が整えられていることを確認せよ。
  許可、モニタリング、アクセスの除去に関するプロセスが整っているべきである。
• システムは、脅威を防ぎ、ネットワークへの意図的な侵入を検知するように設計され、それらの手段がインストールされ、モニタされ、維持されていなければならない。
• ファイアウォールのルールは、通常は、時間と共に変化しがちである。（例：サーバのメンテナンスによるポートの一時的な開放等）　もしレビュが全くされなければ、ファイアウォールのルールは廃れ、望まれていないトラフィックや侵入を許すことになるだろう。

――――――――――――――――――――――――――――――――――――――――

■４－期待

手書き署名の代わりに使用される電子署名は、記録に電子的に署名した職員の真正性とトレースの可能性を保証するために適切な管理がされなければならない。
電子署名は個々の記録と永久的に結びついていなければならない。すなわち、もし、署名された記録に後で変更がなされた場合、記録は、修正を示し、署名されていないものとならなければならない。
電子署名が使用される場合、電子署名は機能的に、署名がされた日時を自動的に記録しなければならない。
電子署名のされたフォームの使用は、より一般的になってきている。（例：会社により、生体認証の使用はより普及してきている。）電子署名のされたフォームの使用が促進されるべきである。

■４－期待を満たさない場合の潜在的なリスク/チェック項目

• 電子署名が適切にバリデートされ、職員への交付が管理され、いつも、電子署名が個人にすぐに帰属可能であることをチェックせよ。
• 電子署名がされた後のデータへの変更は、データが再びレビュされ、再度署名されるまでは、その電子署名は無効化されなければならない。

――――――――――――――――――――――――――――――――――――――――

■５－期待

USBデバイスの使用の制限
システム・セキュリティの理由で、コンピュータ化システムは、GMP/GQPの重要なデータを持つクライアントコンピュータやサーバにおける、USBメモリスティックやストレージデバイスの使用による脆弱性を防ぐための設定がされていなければならない。必要な場合、ポートは、承認された目的のためだけに開放され、全てのUSBデバイスは、使用前に適切にスキャンされなければならない。
GMP/GQPの重要なデータを持つ会社のクライアントコンピュータやサーバにおける個人用のUSBデバイスの使用（フラッシュデバイス、カメラ、スマートホン、キーボード等）、または、個人用コンピュータにおける会社のUSBデバイスの使用は、セキュリティ違反を防ぐために管理されなければならない。

■５－期待を満たさない場合の潜在的なリスク/チェック項目

• オペレーティング・システムの脆弱性が知られた環境では、USBデバイスが、キーボード　のような別の外部装置であることを装うことで、実行ファイルをスタートすることができるということが特に重要である。
• USBデバイスが許可されたユーザの使用に制限するための管理が整備され、USBデバイスが使用される前に、USBデバイスを検査するための手段が整えられるべきである。

まとめ

今回も長くてげっそりされたと思いますが、いかがでしたでしょうか。

色々注意すべき記載がありましたが、個人的に注意すべきと思った点や、最近忘れていた点を下記にピックアップしました。参考にしていただければ幸いです。

• コンピュータ化システムの管理はリスクに応じて実施すべきであること。(9.1.5章)
• システム同士の連携のリスクや脆弱性を理解するために、データフローマップの作成が効果的であること。(9.1.6章)
• システムが外部委託されている場合でも、データ・マネジメントとインテグリティの管理は製薬企業にあること。(9.1.10章)
• 使用中の全てのコンピュータ化システムの台帳を持っていること。(9.3章 ２)
• オペレーティング・システムやネットワーク部品はベンダの提案により、タイムリーに更新されること。
  セキュリティ・パッチはベンダの提案により、タイムリーに適用されること。
  その際、変更管理を実施すること。(9.3章 ６)
• レガシー・システムのデータのアクセス可能性を維持するためには、仮想環境にソフトを置くことも検討すべきであること。（9.4章　３）
• システム管理者は、通常業務と独立した職員が実施することが望ましいこと。
  但し、小さな組織の場合は、兼務も可能であること。その場合、日常業務用ユーザと、管理者用ユーザを分けるべきであること。（9.5章　１）
• ユーザが管理できないコンピュータ化システムは、要件を満たせば紙ベースの管理も可能であること。（9.5章　１）

　

弊社サービスのプロス

https://drmarketing.jp/cch/73/640/3/377/501330/ee3281

★ブログ毎日更新中！

◆ PROS.社長の滋養強壮ブログ

◆ プロス橋本のブログ

【発行責任者】

株式会社プロス　『ASTROM通信』担当　橋本奈央子 hashimoto@e-pros.co.jp

※本記事は株式会社プロスの許可を得て転載しております。