ASTROM通信バックナンバー

月別アーカイブ

2021.09.01

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

~安全な医薬品の安定供給をご支援する~

こんにちは

ASTROM通信担当の橋本奈央子です。

 

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

 

今回も前回に引き続き、202171日に発効した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章 コンピュータ化システムに関するデータ・インテグリティの留意事項 

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 バリデーションとメンテナンス

<システムのバリデーションとメンテナンス>

■1-期待

規制を受ける会社は、データ・マネジメントとインテグリティに関する要件が

システム調達の最初の段階と、システムとデータのライフサイクルを通じて考慮されている

ことを保証するために、適切な管理を文書化して実装しなければならない。規制を受ける

ユーザについては、機能仕様書(FS)、ユーザ要求仕様書(URS)は、データ・マネジメント

とインテグリティの要件に適切に対処しなければならない。

システムがデータ・インテグリティのコントロールに関して購入前に適切に評価されること

を保証するために、GMP/GDPの重要な装置の購入に特別な注意が払わなければならない。

使用中のレガシー・システムは、存在しているシステムの機器構成や機能が、適正なデータ・

マネジメントとインテグリティの管理基準に従って、データの適切な管理が可能なのかどうか

を判断するために評価されるべきである。これらのシステムの機能や設計が適切な管理レベル

を提供しない場合、追加の管理が検討され実装されるべきである。

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

DI(データ・インテグリティ) の要件の不十分な検討により、求められるデータ・

 マネジメントとインテグリティの期待を満たす基本機能を含まないソフトウエアシステム

 を購入することになるかもしれない。

・査察官は、新しいシステムの実装が、DIの原則を適切に考慮した手順に従っていることを

 確認しなければならない。

・いくつかのレガシー・システムは検知の可能性の低いデータの改ざんの余地があり、

 データ・マネジメントに関する適切な管理を含まないかもしれない。

・存在するシステムのアセスメントは、入手可能であり、全ての脆弱性に関する概説と、

 データ・インテグリティを保証するために実装された全ての追加の管理のリストを提供

 しなければならない。追加の管理はバリデートされていなければならず、以下のことを

 含んでいてもよい。

 〇ユーザの特権をコントロールするための管理を含まないソフトウエアの場合、

  オペレーティング・システムの機能の使用

  (例:Windowsのアクティブ・ディレクトリ・グループ)

 〇ソフトウエアでデータファイルの修正/削除の管理ができない場合、ファイルの

  修正/削除を防ぐためのファイル/フォルダに対して許可をする設定操作システム

 〇生成されたデータの管理をするためのハイブリッドまたはマニュアルの仕組みの実装

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

■2-期待

規制を受けるユーザは、使用中の全てのコンピュータ化システムの台帳を持っていなければ

ならない。このリストには以下のことに関する内容を含まなければならない。

-各コンピュータ化システムの名前、設置場所と主要な機能

-機能とシステム及び関連するデータの重要性のアセスメント(例:GMP/GDPへの直接の影響

 あり、非直接の影響あり、何もなし)

-各システムの現在のバリデーションの状態と、存在するバリデーション文書の参照

特に、データ・インテグリティを保証するために必要な管理の評価を行い、各システムの

リスクアセスメントが行われているべきである。データ・インテグリティに関する管理の

バリデーションのレベルと範囲はシステム及び処理の重要性と、製品品質へのリスクの

可能性に基づいて判断されるべきである。例:ロットのリリースデータを生成または管理

する処理やシステムは、一般的に、重要性の低いデータや処理を管理するシステムより

大きな管理が要求される。

より高いリスクの可能性を持つこれらのシステムについて、災害、誤動作、または、

システムが動作不能になることに関する考慮もされるべきである。

アセスメントは、システムの重要な構成設定の不注意もしくは無断の変更や、データの

改ざんに関する脆弱性もレビュすべきである。全ての管理は、文書化され、有効性が

検証されていなければならない。

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

・全てのコンピュータ化システムに関して適切な可視性を持たない会社はシステムの重大性

 を見落とし、データのライフサイクルを通じて脆弱性を生むかもしれない。

・システム台帳は、これらのシステムに対するすべての変更や改良が管理されることを

 保証し、全てのシステムが明確に連携することに役立つ。

・リスクアセスメントが重要な処理装置やデータ収集システムに関して実施されている

 ことを確認せよ。システムの影響の徹底的なアセスメントの欠如は、適切な

 バリデーションとシステムの管理の欠如につながるだろう。レビュするための重要な

 システムの例は、以下の通りである。

  -製品及び原材料の購入やステイタスの管理をするシステム

 -重要な製造工程の管理とデータ収集をするシステム

 -ロットの品質を判断するために使用される、データを生成し、保存し、処理する

  システム

 -ロットの加工や包装の記録に含まれるデータを生成するシステム

 -製品の出荷判定に関する判断の過程で使用されるシステム

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

■3-期待

各コンピュータ化システムのバリデーション・サマリ・レポート(Annex15の要件に

従って書かれ承認されたもの)が整えられ、少なくとも下記の内容が記述(もしくは

参照)されていなければならない。

-重要なシステムの構成設定の詳細と、構成設定へのアクセス制限に関する管理と、

 全ての変更(変更管理)

-ユーザの名前とその役割を明記した、現在許可されている全ての通常のユーザと

 管理ユーザのリスト

-監査証跡とシステムログのレビュの頻度

-下記の手順

 ○新しいシステムユーザの作成

 ○存在しているユーザの修正または権限の変更の手順

 ○各システムのパスワードの組み合わせ/フォーマットの定義

 ○ユーザのレビュと削除の手順

 ○バックアップの手順と頻度

 ○災害復旧

 ○アーカイブしたデータのアクセスと読み取りの手順を含む、データのアーカイブ

  (手順と責任)

 ○データ保管の認められた場所

-レポートは、製造工程または分析作業を復元することを可能にするフォームで

 関連メタデータと共にオリジナルデータがいかに保管されているかを説明しなければ

 ならない。

バリデーション・サマリ・レポートには必要性が書かれていないが、既存のシステム

について、上記の要件を明記した文書が利用できなければならない。これらの文書は、

規制を受けるユーザにより、必要に応じて維持・更新されなければならない。

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

・バリデーションのシステムとレポートが以下のGMP/GDP要件とALCOAの原則を考慮した

 インテグリティの要件に対応していることをチェックせよ。

・システムの構成設定と職務の分離(例:データを生成する権限は、データを検証する

 権限と独立すべきである)がバリデーションの前に定義され、試験中効果的に検証

 されているべきである。

・システムへの改良や変更が制限され、変更管理マネジメントの対象になっていること

 を保証するためのシステムのアクセスに関する手順をチェックせよ。

・システムの管理者アクセスがオーソライズド・パーソンに限定されていて、日常の

 作業で使用されていないことを保証せよ。

 保証するために、その手順をチェックせよ。ユーザのアクセスログと特権レベルを

 チェックせよ。権限のないユーザのシステムへのアクセスがなく、アクセス・アカウント

 は最新化されていなければならない。

・ユーザが監査証跡機能を修正することや、予め設定されたデータファイルが保存される

 ディレクトリ・パスを変更することを防ぐための制限もあるべきである。

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

■4-期待

会社は、コンピュータ化システムのバリデーションに関する具体的な方針と要求事項と

システムや関連データのインテグリティの要求事項を含むバリデーション・マスタ・プラン

を整えなければいけない。

コンピュータ化システムのバリデーションの範囲は、リスクに基づいて判断されなければ

ならない。

コンピュータ化システムバリデーションの要求事項の評価に関する更なるガイドラインは、

PI 011にも記載されているだろう。

システムが日常的な使用に移行する前に、許容範囲に適合することを確認するために

決められたテストが実施されなければならない。

コンピュータ化システムの予測的バリデーションが実施されることが期待される。適切な

バリデーションデータが、既に使用中のシステムにおいて利用可能でなければならない。

コンピュータシステムバリデーションは、必要に応じて、GMP Annex15URS(ユーザ

要求仕様書)、DQ(設計時適格性評価)、FAT(工場出荷試験)、SAT(現地受入試験)、

IQ(据付時適格性評価)、OQ(運転時適格性評価)、PQ(性能適格性評価)の内容に

従って設計されなければならない。

適格性評価の試験のアプローチは、バリデーション中、具体的なシステムに関して調整

され、規制を受けるユーザによって正当である根拠が示されなければならない。適格性

評価には、DQ(設計時適格性評価)、IQ(据付時適格性評価)、OQ(運転時適格性評価)、

PQ(性能適格性評価)を含む。特に、データの品質やインテグリティにリスクがある

分野の試験をするために、固有の試験が計画されるべきである。

会社は、コンピュータ化システムがその使用目的に関して適格性が評価されていること

を保証すべきである。従って、会社は、ベンダの適格性評価されたパッケージだけを

信頼すべきではない;バリデーション活動は、通常の使用と意図した使用が織り込ま

れた作業中にデータのインテグリティが維持されることを保証するため、特定の試験

を含むべきである。

試験の数は、リスクアセスメントにより導き出され、少なくとも重要な機能が特定

されて試験されるべきである。例えば、基本的なアルゴリズムまたはロジックの

組み合わせに基づくPLCやシステムの場合は、機能的試験が、コンピュータ化システム

の信頼性を適切に保証するだろう。重要で、かつ/または、より複雑なシステムは、

IQOQ,PQの段階において詳細の検証試験が必要とされる。

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

・バリデーション文書がデータ・インテグリティに関する固有の条項を含んでいる

 ことを確認せよ;バリデーション・レポートは、データ・インテグリティの原則に

 対応し、設計と試験を通じて適切な管理が整っていることを示すべきである。

・バリデートされていないシステムは、ユーザのアクセスやシステム設定がデータ

 の修正を許す可能性があるので、データ・インテグリティに関して重大な脆弱性

 が存在するかもしれない。

・エンド・ユーザの試験は、ソフトウエアがベンダの要件を満たすだけでなく、その

 意図した使用に合っていることを示すために設計されたテストスクリプトを含んで

 いることをチェックせよ。

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

■5-期待

定期的なシステム評価

コンピュータ化システムは、データ・インテグリティの管理を考慮した継続的な

コンプライアンス状態にあることを保証するために定期的に評価されるべきである。

評価は、逸脱、変更(変更の全ての蓄積された影響を含む)、アップグレードの

履歴、性能とメンテナンスを含むべきである。また、これらの変更がデータ・

マネジメントとインテグリティの管理に有害な影響を与えなかったかを評価すべき

である。

再バリデーションの頻度は、前回のレビュからシステムに対して実施された変更の蓄積

された影響を考慮し、コンピュータ化システムの重要性によるリスクアセスメントに

基づくべきである。実施されたアセスメントは文書化されるべきである。

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

・バリデーション・スケジュールの中に、コンピュータ化システムの再バリデーション

 のレビュの概要が述べられていることをチェックせよ。

・システムが、特にデータ・インテグリティに関する全ての潜在的な脆弱性を考慮し、

 定期的なレビュの対象になっていることを確認せよ。

・既存のソフトウエア/ハードウエアの欠点などの、確認された全ての問題がタイムリー

 に対処され、確認された全てのリスクを管理するために是正処置・予防処置や暫定的

 な管理が利用可能で実施されるべきである。

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

■6-期待

オペレーティング・システムとネットワーク部品(ハードウエアを含む)はベンダの提案

に従ってタイムリーに更新され、古いプラットフォームから新しいプラットフォームへ

のアプリケーションの移行は、システムにより生成されたデータのマネジメントと

インテグリティに影響を与えうることになるプラットフォームがサポートされない状態

になる前に計画され、実行されるべきである。

オペレーティング・システムとネットワーク部品のセキュリティ・パッチは、データの

安全性を維持するために、ベンダの提案に従って、管理されたタイムリーな方法で適用

されるべきである。セキュリティ・パッチの適用は、変更管理の原則に従って実施される

べきである。

サポートされていないオペレーティング・システムが維持される場合、即ち、古い

オペレーティング・システムについて、ベンダもしくはサポートされたバージョンの

セキュリティのパッチがあてられる期間が切れた後は、システム(サーバ)は、可能な

限り、その他のネットワークから隔離されるべきである。残ったインタフェースと他の

装置へ/からのデータの転送は、サポートされていないオペレーティング・システムに

より引き起こされる脆弱性の発生を防ぐために慎重に設計され、設定され、適格性を

評価されなければならない。サポートがされていなシステムは、固有の脆弱性のリスク

により、リモートアクセスは慎重に評価されるべきである。

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

・システムのアップデートは、管理されたタイムリーな方法で実施されていることを

 確認せよ。古いシステムは、適切なデータ・インテグリティの管理が統一されている

 こと、または、(統一した管理が不可能な場合は)適切な管理が実装されていて効果的

 であることが十分にレビュされるべきである。

 

9.4 データ転送

<データ転送と移行>

■1-期待

インタフェースは、正しく完全なデータの転送を保証するために、バリデーション中に

評価され対処されるべきである。

インタフェースは、データ・インテグリティのリスクを最小化するために、正しい安全な

データの入力と処理に関する適切な組み込みのチェックを含むべきである。検証方法は、

下記の使用を含むとよい。

○安全な転送

○暗号化

○チェック・サム(※データ通信におけるエラー検出方法の一つ)

可能であれば、システム間のインタフェースは、GMP/GQPデータの転送の自動化を含めて

設計され、検証されるべきである。

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

・コンピュータ化システム間のインタフェースは、転送中に、データが気づかずに失われ

 たり、間違って修正されたり書き換えられたりするリスクをもたらす。

・データが安全な場所/データベースに直接転送され、ローカル・ドライブ(変更される

 可能性がある場所)から簡単にコピーされないことを保証せよ。

・最終的なデータ保管場所またはデータ処理場所に転送される前のローカルな

 コンピュータ化システム(例:機器のコンピュータ)の一時的なデータ保管場所は、

 データが消されたり、改ざんされたりする可能性を作る。これは、スタンドアロン

 (ネットワークでつながっていない)システムの固有のリスクである。最初にデータ

 が保管された環境は適切なデータ・インテグリティの管理が整っていることを保証せよ。

・うまく設計され、適格性評価がされている自動データ転送は、人により実施される

 いかなる手動データ転送より信頼できる。

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

■2-期待

システムのソフトウエア(オペレーティングシステムを含む)がインストールもしくは

アップデートされる場合、ユーザは、アーカイブされたデータが新しいソフトウエアで

読めることを保証すべきである。これは、必要に応じて、存在しているアーカイブされた

データの新しいフォーマットへの変換が求められるかもしれない。

データが新しいソフトウエアの新しいデータ・フォーマットに変換が出来ない場合、

古いソフトウエアは、例えば1つのコンピュータ内にインストールされるか、他の技術的

解決策により維持され、査察時にアーカイブされたデータを読むために

バックアップメディアとして利用可能でなければならない。

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

・データのライフサイクルを通じて、データはそのもともとの形式で読めることが重要で

 ある。従って、ユーザは、データの可読性を維持しなければならず、廃止されたソフト

 ウエアへのアクセスを保持することが求められるかもしれない。

1つのシステムから別のシステムへのデータの移行は、管理された方法で、文書化手順

 に従って実施され、データの完全な移行の適切な検証を含まなければいけない。

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

■3-期待

レガシー・システムのソフトウエアがもはやサポートされない場合、データのアクセス可能性

 (特定の保管要件によりできるだけ長く))のために、ソフトウエアの維持に関して考慮される

べきである。これは仮想環境にソフトウエアを保持することで達成されるかもしれない。

可能な限り“真正なコピー”の属性をもった他のファイルフォーマットへの移行は、年数が

経過するレガシー・データに必要になるかもしれない。

オリジナルのデータの機能完全に備えた移行が技術的に可能でない場合、代替手段が、リスク

とデータの重要性に基づいて時間と共に評価されるべきである。移行ファイルフォーマット

は、長期間のアクセス可能性 対 動的データの機能(例:データの問い合わせ、トレンド、

再加工)の減少の可能性を考慮して選択されるべきである。リスクアセスメントは、システム

の重要な構成設定へのうっかりした、または、許可されない変更や、データの改竄に対する

脆弱性のレビュもすべきである。リスクを軽減するための全ての管理は文書化され、それら

の有効性が検証されるべきである。アクセス可能性を維持するために、いくつかの属性・

動的データの機能を失うファイルフォーマットへの移行を必要とするかもしれないことは

受け入れられる。

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

・ソフトウエアが仮想環境に保持される場合、ソフトウエアを管理するための適切な手段

 (例:バリデーション状態、許可された職員によるアクセス管理)が整っていることを

 チェックせよ。全ての管理は文書化され、それらの有効性が検証されるべきである。

 

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

<システム・セキュリティ>

■1-期待

ユーザのアクセス管理は、データへの権限のないアクセスや変更や削除を禁止するために

設定され、強化されなければならない。セキュリティ管理の範囲は、コンピュータ化

システムの重要性による。例えば:

-個々のログインIDとパスワードは、電子システムにアクセスし利用する必要のある全て

 のスタッフに設定され、与えられなければならない。共有されたログイン認証情報は、

 活動を行った個々のトレーサビリティのために、許されない。この理由から、経済的な

 節約のためであっても、共有パスワードは禁止されるべきである。

 ログイン・プロファイル、構成設定、パスワードのフォーマットが明確に定義され、

 意図した通りに機能することを保証するために、電子システムのバリデーション中に

 検証されるべきである。

-コンピュータ化された記録に対するデータの入力と変更は、許可された職員によって

 のみ実施されるべきである。会社は、使用中の各電子システムについて、アクセスを

 許可された個人と、彼らのアクセス権限のリストを保持すべきである。

-システムが効果的に保護されていることを保証するために、パスワードのフォーマット

 と使用に関する適切な管理が行われるべきである。

-はじめに許可されたシステムのアクセスに基づき、システムは、通常のパスワードの

 ルールに従い、ユーザが新しいパスワードを作ることを許可しなければならない。

-システムは、ユーザのさまざまなアクセスの役割(レベル)をサポートし、役割の

 割り当ては、最低限の特権付与のルール、すなわち、いかなるジョブの機能に

 対しても最低限必要なアクセスレベルを付与すること、に従うべきである。最低限

 として、シンプルなシステムは、通常ユーザと管理ユーザを持つべきだが、より複雑

 なシステムは、通常は、アクセス管理を効果的にサポートするためにユーザにより

 多くのレベル(例:階層)が必要になるだろう。

-GMP/GQPの重要なアプリケーションを運営するために、コンピュータシステムや

 インフラへの管理者のアクセス権限を許可することは、厳しく管理されるべきである。

 管理者のアクセス権限は、システムの通常のユーザに与えられるべきではない。

 (職務の分離)

-通常のユーザは、コンピュータシステムの重要な局面へのアクセス権限を持つべきで

 ない。(例:システム・クロック、ファイルの削除機能等)

-システムは、システムに実際にアクセスしたユーザの名前と役割を含むリストを作る

 ことができるべきである。そのリストは、定期的なユーザのレビュ中に用いられる

 べきである。ユーザのリストは、名前または特定の個人を識別できるユニークな識別子

 を含むべきである。このリストは、定期的なユーザのレビュ中に使用されるべきである。

-システムは、下記の情報を含んだ、ログインの試みの成功と失敗のリストを作ることが

 できるべきである。

 ユーザの名前

 ユーザの役割

 ログインを試みたローカル時間、または、ローカル時間がトレースできる日時

 セッション(交信)の長さ(ログイン成功時)

-ユーザのアクセス管理は、役割の厳格な分離を確実に行うべきである。(すなわち、

 通常の業務を行うシステムの全ユーザは、通常のアクセス権限のみを持つべきである。)

 普通は、高いアクセス権限を持ったユーザ(例:管理者)は、システムで通常業務を

 実施すべきでない。

-システム管理者は、通常、ユーザの実施する業務と独立し、生成されたデータに関与

 や関心を持ってはいけないし、電子システムを利用できてはいけない。例えば、QC

 管理者やマネージャは、試験室の電子システム(例:HPLCGCUVVis)の

 システム管理者に任命されるべきではない。通常は、品質や製造の組織の外部の人間

 (例:情報技術の管理者)がシステム管理者の役目を果たし、高度な許可レベルを

 持つべきである。

-より小さな組織の場合、品質部門や製造部門で指名された人間がシステム管理者として

 アクセス権限を持つことは許容してもよい。しかし、これらの場合、管理者のアクセス

 は、日常作業の実施に用いられるべきではなく、ユーザは、第二の日常作業の実施用の

 制限されたアクセス権限を持つべきである。これらの場合、管理者の実施した全ての

 活動は、記録され、品質システム内で承認されるべきである。

-新しいユーザ、新しいユーザの権限に関する全ての要求は、適切な職員(例:ライン

 のマネージャ、システムオーナ)に許可され、標準手順に従ってトレース可能な

 方法でシステム管理者に送付されなければならない。

-GMP/GQPの重要なデータや作業にアクセスするコンピュータシステムは、事前に定義

 した時間よりも長い間不応のユーザを、アプリケーションまたはオペレーション・

 システムレベルでログアウトする非活動ログアウト機能を持つべきである。その時間

 は、通常は、長くするのではなく、システムへの権限のないアクセスを防ぐために

 短く設定されるべきである。非活動ログアウトの有効化に加え、システムは、

 再ログインのために通常の認証手順を要求すべきである。

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

・会社が、使用中のコンピュータ化システムが安全で、意図的またはうっかりした変更

  から保護されていることを保証するためにあらゆる合理的なステップを踏んでいる

 ことをチェックせよ。

・物理的かつ管理上保護されていないシステムは、データ・インテグリティの点で脆弱

 である。査察官は、コンピュータ化システムがバリデートされ、改ざんから保護

 された状態が保たれていることを保証する、システムのセキュリティを管理する検証

 された手順が存在することを確認すべきである。

・個々のユーザログインIDが使用されていることを確認せよ。システムの構成設定が、

 個々のユーザのログインIDの使用を認めている場合、これらが使用されるべきである。

・一部のコンピュータ化システムは、単一ユーザのログイン、または、限定された人数

 のユーザのログインのみをサポートしていることが認識されている。適切な代替の

 コンピュータ化システムが利用できない場合、サードパーティのソフトウエア、

 または、トレーサビリティ(バージョン管理と共に)を提供する紙ベースの方法に

 よる同等の管理が提供されてもよい。代替システムの適合性は、正当化され、文書化

 されなければならない。ハイブリッドシステムについては、さらなるデータレビュが

 求められることがありうる。

・査察官は、システムが適切なパスワードのルールを強制し、強固なパスワードを要求

 することを保証するためにパスワードの方針が整っていることを確認すべきである。

 重要なデータを生成し処理するシステムには、より強固なパスワードを使用するため

 の検討がなされるべきである。

・ユーザによって新しいパスワードが変更できず、管理者のみがパスワードを作れる

 システムは、パスワードの信頼性が保持できないので、データ・インテグリティに

 合わない。

・ユーザのアクセスレベルが適切に定義され、文書化され、管理されていることを

 チェックせよ。ユーザの単一のアクセスレベルを使用し、この役割を全ユーザに

 割り当てることは、定義次第でアクセスレベルは管理者の権限になるので、

 容認できない。

・許可された個人だけがシステムを使用でき、電子的に記録に署名し、操作を行い、

 入力または出力装置にアクセスし、記録を変更し、または手近で作業が行えること

 を保証するために、システムは管理者がチェックしていることを確認せよ。

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

■2-期待

コンピュータ化システムは、偶然の変更や意図的な改ざんから保護されているべきで

ある。会社は、最終的にデータ・インテグリティに影響を与えうるバリデートされた

設定に対する許可のない変更を防ぐためにシステムとその設計を評価すべきである。

以下の考慮がされるべきである。

-コンピュータ化システムのハードウエアの物理的セキュリティ:

 〇サーバの場所とアクセス制限

 PLCモジュールへのアクセス制限(例:点検用パネルの錠締め)

 〇コンピュータ、サーバ、メディアへの物理的なアクセスは、許可された個人に限定

   されるべきである。通常は、システムのユーザは、サーバやメディアに対する

   アクセス権限を持つべきでない。

-ローカルや外部の攻撃からのネットワークシステムの脆弱性

-リモートのネットワークの更新(例:ベンダによるネットワークシステムの自動更新)

-システムの設定、構成や重要データのセキュリティ

 システムの重要なデータ/操作パラメータへのアクセス権限は適切に制限され、

 設定/構成の変更は、権限を与えられた職員により変更マネジメント手順を通じて管理

 されていなければならない。

-システム時間は、接続するシステムの時計と同期され、全ての時計へのアクセスは

 権限を与えられた職員に限定されるべきである。

-侵入の防止と検知のシステムを含む、適切なネットワークのセキュリティの手段が

 適用されるべきである。

-ファイアウォールは、重要なデータや作業を守るためにセットアップされていな

 ければならない。ポートの開放(ファイアウォールのルール)は、可能な限り厳しくし、

 許可されたトラフィックのみを許可し、最低限の特権付与方針に基づくべきである。

 規制を受けるユーザは、ネットワークセキュリティの手段(例:潜在的なセキュリティ

 の弱さを特定するためのITインフラのネットワークの脆弱性のスキャンの使用)の

 継続的な妥当性と効果の定期的なレビュを実施し、オペレーティング・システムが

 現在のセキュリティ手段を維持していることを保証しなければならない。

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

・ハードウエアとソフトウエアへのアクセスが適切に保護され、権限を与えられた職員

  に限定されていることをチェックせよ。

・適切な認証方法が実装されていることを確認せよ。これらの方法は、ユーザID

  パスワードを含んでいるか、他の方法でもよいが、認証が要求されなければならない。

 ユーザが確実に特定可能であることが必須である。

・インターネット経由で利用できる重要なデータを含むシステムのリモートの認証に

 ついては、パスコード・トークンや生体認証の使用などの追加の認証技術が使用

 されていることを確認せよ。

・システムの重要な操作パラメータへのアクセスが適切に管理され、システムが、

 GMP/GQPの手順において、イベントやパラメータやの正しい順番を強制することを

 確認せよ。

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

■3-期待

ネットワークの保護

ネットワークシステムのセキュリティは、データへの潜在的な脅威を検知し防ぐための

適切な方法を含むべきである。

実装されるネットワークの保護のレベルは、データのリスクのアセスメントに基づくべき

である。

ファイアウォールが、許可されないアクセスに使用されるべきであり、ファイアウォール

のルールは、許可されたトラフィックのみ許可し、必要であれば制限をかけるように設定

されていることを保証するために、定期的なレビュの対象とされるべきである。レビュは

文書化されていなければならない。

ファイアウォールは、意図的な攻撃やマルウェアからデータやコンピュータ化システムを

守るために、適切なウイルス保護または侵入の防止/検知システムと共に補完されなければ

ならない。

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

・不十分なネットワークのセキュリティは権限のないアクセスや誤用や修正による

 システムの脆弱性に関連したリスクをもたらす。

・ネットワークのアクセスを管理するための適切な方法が整えられていることを確認せよ。

 許可、モニタリング、アクセスの除去に関するプロセスが整っているべきである。

・システムは、脅威を防ぎ、ネットワークへの意図的な侵入を検知するように設計され、

 それらの手段がインストールされ、モニタされ、維持されていなければならない。

・ファイアウォールのルールは、通常は、時間と共に変化しがちである。(例:サーバ

 のメンテナンスによるポートの一時的な開放等) もしレビュが全くされなければ、

 ファイアウォールのルールは廃れ、望まれていないトラフィックや侵入を許すことに

 なるだろう。

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

■4-期待

手書き署名の代わりに使用される電子署名は、記録に電子的に署名した職員の真正性と

トレースの可能性を保証するために適切な管理がされなければならない。

電子署名は個々の記録と永久的に結びついていなければならない。すなわち、もし、署名

された記録に後で変更がなされた場合、記録は、修正を示し、署名されていないものと

ならなければならない。

電子署名が使用される場合、電子署名は機能的に、署名がされた日時を自動的に記録しな

ければならない。

電子署名のされたフォームの使用は、より一般的になってきている。(例:会社により、

生体認証の使用はより普及

してきている。)電子署名のされたフォームの使用が促進されるべきである。

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

・電子署名が適切にバリデートされ、職員への交付が管理され、いつも、電子署名が個人

 にすぐに帰属可能であることをチェックせよ。

・電子署名がされた後のデータへの変更は、データが再びレビュされ、再度署名される

 までは、その電子署名は無効化されなければならない。

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

■5-期待

USBデバイスの使用の制限

システム・セキュリティの理由で、コンピュータ化システムは、GMP/GQPの重要なデータ

を持つクライアントコンピュータやサーバにおける、USBメモリスティックやストレージ

デバイスの使用による脆弱性を防ぐための設定がされていなければならない。必要な場合、

ポートは、承認された目的のためだけに開放され、全てのUSBデバイスは、使用前に適切

にスキャンされなければならない。

GMP/GQPの重要なデータを持つ会社のクライアントコンピュータやサーバにおける個人用

USBデバイスの使用(フラッシュデバイス、カメラ、スマートホン、キーボード等)、

または、個人用コンピュータにおける会社のUSBデバイスの使用は、セキュリティ違反を

防ぐために管理されなければならない。

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

・オペレーティング・システムの脆弱性が知られた環境では、USBデバイスが、キーボード

 のような別の外部装置であることを装うことで、実行ファイルをスタートすることが

 できるということが特に重要である。

USBデバイスが許可されたユーザの使用に制限するための管理が整備され、USBデバイス

 が使用される前に、USBデバイスを検査するための手段が整えられるべきである。

 

 

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

まとめ

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

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

 

色々注意すべき記載がありましたが、個人的に注意すべきと思った点や、最近忘れて

いた点を下記にピックアップしました。参考にしていただければ幸いです。

・コンピュータ化システムの管理はリスクに応じて実施すべきであること。(9.1.5)

・システム同士の連携のリスクや脆弱性を理解するために、データフローマップの

 作成が効果的であること。(9.1.6)

・システムが外部委託されている場合でも、データ・マネジメントとインテグリティ

 の管理は製薬企業にあること。(9.1.10)

・使用中の全てのコンピュータ化システムの台帳を持っていること。(9.3章 2)

・オペレーティング・システムやネットワーク部品はベンダの提案により、タイムリー

 に更新されること。

 セキュリティ・パッチはベンダの提案により、タイムリーに適用されること。

 その際、変更管理を実施すること。(9.3章 6)

・レガシー・システムのデータのアクセス可能性を維持するためには、仮想環境に

 ソフトを置くことも検討すべきであること。(9.4章 3)

・システム管理者は、通常業務と独立した職員が実施することが望ましいこと。

 但し、小さな組織の場合は、兼務も可能であること。その場合、日常業務用ユーザと、

 管理者用ユーザを分けるべきであること。(9.5章 1)

・ユーザが管理できないコンピュータ化システムは、要件を満たせば紙ベースの管理も

 可能であること。(9.5章 1)

 

☆次回は、9.6章以降を、9/15(水)に配信させていただきます。

 

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

無料WEBセミナのご案内

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

グループ会社(キッセイコムテック株式会社)では、RPA等を活用した業務効率の向上に

関する無料WEBセミナを開催します。

1時間程度のセミナですので、手軽にご参加いただけるかと思います。

ご興味がおありの方は、下記URLからお申込みください。

 

【セミナ】

イベント名:AI-OCRAxisRead/RPAAxisRobo/クラウドストレージ

AxisDrive」業務改善セミナ

日程: 97() 1400-1500

申込HPhttps://www.kicnet.co.jp/events/event/e210720/

 

 

◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇

★弊社サービスのご案内

https://drmarketing.jp/cch/73/497/3/425/369633/0de707

 

★ブログ毎日更新中!

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

https://drmarketing.jp/cch/73/497/1/425/369633/80d1b3

◆ プロス橋本のブログ

https://drmarketing.jp/cch/73/497/2/425/369633/65204a

 

 

本メルマガは、名刺交換させていただいた方に毎月1日、15日に配信いたしております。

今後このような情報が必要ない方は、お手数ですが、こちらに配信停止依頼のメールを

お願いいたします。

hashimoto@e-pros.co.jp

 

【発行責任者】

株式会社プロス

ASTROM通信』担当 橋本奈央子ここにエントリー本文を書きます。