
クローズドシステムとオープンシステムの違い
21 CFR Part 11 では、クローズドシステムとオープンシステムを区別している。それはなぜであろうか。両者では、電子記録が晒されるリスクの質がまったく異なるからである。本篇では、まず Part 11 の条文が両者をどう定義しているかを原文で確認したうえで、実務上その差が最も顕著に表れる「インターネットを介した通信環境」を題材に、オープンな環境で生じる三大リスク——盗聴・改ざん・なりすまし——がなぜ発生するのかを解説する。そのうえで、それぞれのリスクに対してどのような対策が有効かを示す。
Part 11 の定義を原文で確認する
クローズドシステムとオープンシステムの定義は、21 CFR §11.3(b) の定義規定に置かれている。
(訳:クローズドシステムとは、システム上の電子記録の内容に責任を負う者によってシステムへのアクセスが管理されている環境をいう。)
――21 CFR §11.3(b)(4)(eCFR 原文)
(訳:オープンシステムとは、システム上の電子記録の内容に責任を負う者によってシステムへのアクセスが管理されていない環境をいう。)
――21 CFR §11.3(b)(9)(eCFR 原文)
判断基準はここにある
- 条文が置いている唯一の判断基準は、「システムへのアクセスが、当該電子記録の内容に責任を負う者によって管理されているか否か」である。
- 「インターネットに繋がっているか」「社内にあるか社外にあるか」は、条文上の定義そのものではない。あくまで、アクセス管理の主体が誰かを判断する際の重要な手がかりにすぎない。
- とはいえ実務上、両者は強く相関する。不特定多数が接続できる公共インフラを経路に含めれば、記録内容に責任を負う者がアクセスを掌握できなくなるのが通例だからである。以下ではこの典型例を軸に解説する。
| 比較項目 | クローズドシステム(§11.3(b)(4)) | オープンシステム(§11.3(b)(9)) |
|---|---|---|
| 条文上の判断基準 | 電子記録の内容に責任を負う者が、システムアクセスを管理している | 電子記録の内容に責任を負う者が、システムアクセスを管理していない |
| 典型例 | 組織が経路と権限を掌握する社内LAN上のシステム | 不特定多数が接続可能な公共インフラを経路に含むシステム |
| 適用される要件条文 | §11.10(クローズドシステムの管理) | §11.30(§11.10 を適宜含めたうえで追加措置) |
| 保護すべき範囲 | 電子記録の真正性・完全性、必要に応じ機密性 | 記録の作成時点から受領時点までの真正性・完全性・(適切な場合)機密性 |
| 追加で例示される措置 | ― | 文書の暗号化、適切なデジタル署名標準の使用 |
| よくある誤解 | 「社内にあるからクローズド」――設置場所は基準ではない | 「クラウドだからオープン」――接続形態は基準ではない |
要件はどう変わるのか
| 区分 | 適用条文 | 求められる管理 |
|---|---|---|
| クローズドシステム | §11.10 | 電子記録の真正性・完全性、必要に応じ機密性を確保し、署名者が署名済み記録を容易に否認できないようにする手順・管理。具体的には、バリデーション(a)、人が読める形式と電子形式での正確・完全な複製の生成(b)、保存期間を通じた正確かつ迅速な検索の確保(c)、権限者へのアクセス制限(d)、安全で computer-generated かつタイムスタンプ付きの監査証跡(e)、操作順序チェック(f)、権限チェック(g)、デバイス(端末)チェック(h)、教育訓練(i)、文書化された方針による責任の明確化(j)、システム文書の管理(k)。 |
| オープンシステム | §11.30 | 記録の作成時点から受領時点まで、真正性・完全性・(適切な場合には)機密性を確保する手順・管理。§11.10 の管理を適宜含めたうえで、さらに追加措置——具体的には文書の暗号化および適切なデジタル署名標準の使用など——を講じることが求められる。 |
すなわち、オープンシステムの要件は「クローズドシステムの要件 + α」である。追加される α の中身が、条文上は暗号化とデジタル署名標準として例示されている。これは偶然ではない。以下で見るとおり、暗号化は盗聴に、デジタル署名は改ざんとなりすましに、それぞれ正面から対応する技術だからである。
▲【動画】株式会社イーコンプライアンス YouTube公式チャンネルより
オープンシステムは「常時存在する」ものではない
ここで一つ、直感に反するが重要な事実を押さえておきたい。オープンシステムというものは常時存在しているわけではない。クローズドシステムとクローズドシステムをインターネットを介して接続したときに、はじめてオープンシステムが立ち現れるのである。
例えば、Amazonや楽天のようなネットショッピング、JAL・ANA・JRなどのチケット販売がそれにあたる。読者の家庭にあるPCなどはそれ単独ではクローズドシステムであり、Amazonのサーバーもそれ単独ではクローズドシステムである。PCとサーバーをインターネットで接続した際に、はじめてオープンシステムが出現する。
このとき何が起きているか。記録の内容に責任を負う者が管理できる範囲を、通信経路が飛び出してしまうのである。だからこそオープンシステムにおいては盗聴・改ざん・なりすましという三大リスクが発生する。Part 11 がオープンシステムに厳しい要件を課している所以である。
クローズドシステムとは何か
実務上、クローズドシステムの典型例が企業の社内LAN(Local Area Network)である。外部のネットワーク(主にインターネット)から物理的または論理的に切り離された通信環境であり、通信はすべて組織が管理するネットワーク機器(スイッチ、ルーター、ファイアウォール等)の内側で完結する。
外部との接点が存在しないため、悪意ある第三者がネットワーク上の通信に割り込む機会は、物理的なアクセスを除けばほぼ存在しない。この「外と繋がっていない」という性質こそが、クローズドシステムの安全性の根拠である。言い換えれば、信頼できる者しか存在しない閉じた空間で通信が行われているという前提が成り立っている。そしてこの前提こそが、§11.3(b)(4) にいう「記録内容に責任を負う者がアクセスを管理している」状態を成立させている。
オープンシステムとは何か
これに対しオープンシステムの典型は、インターネットを介した通信環境である。インターネットは世界中の無数のルーターやサーバーによって構成される公共インフラであり、誰もが接続できる開かれたネットワークである。
ここで重要な事実がある。インターネット上でAというコンピュータからBというコンピュータへデータを送る場合、そのデータは第三者が管理する多数の中継装置を経由する。送信者も受信者も、その経路を完全にコントロールすることはできない。
この「経路が制御できない」という構造的特性が、三大リスクの温床となる。そしてこれはまさに、条文が言う「記録内容に責任を負う者がアクセスを管理していない」状態そのものである。
三大リスクの正体
リスク①:盗聴(Eavesdropping)
盗聴とは、通信の途中でデータの内容を第三者に読み取られることである。
社内LANではネットワーク機器が組織の管理下にあるため、通信内容を無断で傍受することは困難である。しかしインターネット上では、中継装置を管理する組織が多岐にわたり、かつその一部が悪意ある者によって制御されている可能性を排除できない。
平文(暗号化されていないテキスト)でデータを送信した場合、その内容はパケットキャプチャ等の技術によって容易に読み取られる恐れがある。かつてHTTPが主流であった時代、IDやパスワードが平文で流れており、盗聴のリスクが深刻な問題であった。
リスク②:改ざん(Tampering)
改ざんとは、送信されたデータの内容が、受信者に届くまでの間に第三者によって書き換えられることである。
クローズドシステムでは通信経路が組織内で完結しているため、外部からデータを書き換えることは極めて困難である。しかしオープンな環境では、中継点においてデータを書き換える中間者攻撃(Man-in-the-Middle Attack、MitM攻撃)が成立しうる。なお、MitM攻撃は改ざんだけでなく、盗聴・なりすましを同時に実現しうる複合的な攻撃手法であり、三大リスク全体に関わる点を念頭に置いておきたい。
例えば、金融機関への振込指示が途中で書き換えられ、別の口座に送金されるといった被害は、改ざん攻撃の典型例である。データが「正しく届いたか」を検証する仕組みがなければ、受信者は改ざんに気づくことができない。GxPの文脈で言えば、これは記録の完全性(integrity)が損なわれる事態であり、「改ざん」の本当の定義とは何か でも取り上げているとおり、データインテグリティの中核に関わる問題である。
リスク③:なりすまし(Spoofing / Impersonation)
なりすましとは、通信の相手が「本当に意図した相手かどうか」を確認できない状況を利用した攻撃である。
社内LANでは、通信相手のIPアドレスやMACアドレスが組織内で管理されており、ある程度の同一性確認が可能である。ただしMACアドレスはソフトウェアで偽装(MACスプーフィング)することが可能であり、LAN内でもARPスプーフィング攻撃が成立しうることに注意が必要である。クローズドシステムにおけるセキュリティは、厳格に管理された物理環境での運用が前提となっている点を押さえておくべきである。
しかしインターネット上では、送信元のアドレスは技術的に偽装可能であり、「有名企業のサーバー」を装った偽サイトや偽メールを容易に構築できる。フィッシング詐欺はなりすましの最も身近な例であり、利用者が本物と見分けのつかない偽サイトに誘導され、認証情報を盗取される事案が後を絶たない。
| リスク | 侵害される性質 | クローズド環境での状況 | 有効な対策 |
|---|---|---|---|
| 盗聴 | 機密性(Confidentiality) | 経路が組織管理下にあり傍受は困難 | 通信の暗号化(TLS/HTTPS、VPN) |
| 改ざん | 完全性(Integrity) | 外部からの書き換えは極めて困難 | ハッシュ値による検証、デジタル署名 |
| なりすまし | 真正性(Authenticity) | アドレス管理により一定の確認が可能(ただし偽装の余地あり) | PKI・デジタル証明書による相手の検証 |
この表を §11.30 の条文と並べてみてほしい。§11.30 が求める「authenticity, integrity, and, as appropriate, the confidentiality(真正性・完全性・適切な場合には機密性)」は、三大リスクが侵害するもののちょうど裏返しである。条文の構成は、この三つのリスクを前提に組み立てられているのである。
三大リスクへの対策
対策①:暗号化による盗聴対策
盗聴対策の基本は通信内容の暗号化である。現在のWebにおけるHTTPS(HTTP over TLS)はその代表例であり、送受信されるデータをTLSプロトコルで暗号化することで、中継点での傍受を無意味にする。
また、VPN(Virtual Private Network)を利用することで、インターネット上に仮想的な専用回線(トンネル)を構築し、クローズドシステムに近い通信環境を実現することも可能である。TLSの設定水準については、米国NISTの SP 800-52 Rev.2(Guidelines for the Selection, Configuration, and Use of TLS Implementations) が公的な指針として参照できる。
§11.30 が「document encryption(文書の暗号化)」を明示的に挙げているのは、まさにこの対策を指している。なお条文が求めているのは通信経路の暗号化に限らず、文書そのものの暗号化である点に留意したい。
対策②:ハッシュ値・デジタル署名による改ざん検知
データが改ざんされていないことを検証するためには、ハッシュ関数が用いられる。送信前のデータからハッシュ値(データの指紋に相当する固定長の値)を算出し、受信後に同じ計算を行って比較する。値が一致すれば改ざんが行われていないことを確認できる。
さらにデジタル署名を組み合わせることで、「このデータは特定の送信者が作成したものであり、内容が変更されていない」ことを暗号学的に証明することが可能である。Part 11 が §11.3(b)(5) でデジタル署名を定義し、§11.30 で「適切なデジタル署名標準の使用」を求めているのは、この機能を期待してのことである(電子署名とデジタル署名の違い)。ここでいう「デジタル署名標準」の代表例が、米国NISTの FIPS 186-5(Digital Signature Standard, DSS) である。
対策③:デジタル証明書・認証基盤によるなりすまし防止
なりすまし対策の核心は、通信相手の正当性を第三者機関が保証する仕組みにある。これを実現するのがPKI(公開鍵基盤)とデジタル証明書である。
信頼できる認証局(CA)が発行したデジタル証明書を持つサーバーは、「本物である」ことが保証される。HTTPSにおいて、ブラウザがサーバーの証明書を検証するのはこのためである。
かつてブラウザのURLバーに表示されていた南京錠アイコンはHTTPS接続の証として広く認知されていたが、Google Chromeはバージョン117(2023年9月)以降、このアイコンを設定メニューを示す別の表示に変更した。南京錠アイコンは「HTTPS通信が確立されていること」を示すに過ぎず、「そのサイトが安全・信頼できること」を保証するものではないという誤解を招きやすかったためである。証明書の正当性はアイコンではなく証明書の詳細情報で確認することが望ましい。
クローズドでも油断は禁物
ここまでクローズドシステムの優位性を述べてきたが、一点注意が必要である。クローズドシステムは外部からの攻撃を防ぐ点では優れているが、内部からの脅威(インサイダー脅威)には本質的に無防備である。
組織内の悪意ある関係者、または不注意による内部漏えいは、どれほど堅牢なクローズド環境であっても防ぐことができない。このため、現代のセキュリティ設計では「内側も信頼しない」というゼロトラストアーキテクチャの考え方が広まりつつある。
Part 11 がクローズドシステムに対しても §11.10 で、権限者へのアクセス制限(d)、監査証跡(e)、権限チェック(g)、端末チェック(h)、そして記録・署名の偽造を抑止するための責任の明確化(j) を求めているのは、まさに内部脅威を織り込んでいるからにほかならない。「クローズドだから §11.10 の管理は軽くてよい」という理屈は、条文上どこにも存在しない(コンピュータ化システムにおける端末チェックとは)。
実務でのチェックポイント
- 対象システムについて、電子記録の内容に責任を負う者は誰かを先に特定する。ここが曖昧なままでは、クローズド/オープンの判定はできない。
- その責任者が、アカウント発行・権限付与・権限剥奪・アクセスログの確認を実際に掌握しているかを確認する。契約書や手順書上の建て付けだけでなく、運用実態で確認する。
- オープンシステムと判定した場合は、§11.10 の各管理に加えて、文書の暗号化とデジタル署名標準の使用を検討し、採否とその理由をリスクアセスメントの記録として残す。
- 判定の根拠は必ず文書化する。査察で問われるのは判定結果そのものより、どのような根拠でそう判断したかである。
なお、そもそも Part 11 がどのような場合に適用されるのかという前提については プレディケートルールとは を、認証手段として生体認証を用いる場合の留意点については バイオメトリクスの問題点 をあわせて参照されたい。
まとめ――3つのポイント
- 判断基準は「誰がアクセスを管理しているか」§11.3(b)(4)/(9) が置く基準は、電子記録の内容に責任を負う者によってシステムアクセスが管理されているか否か、この一点である。設置場所や接続形態は、その判断のための手がかりにすぎない。
- オープンシステムには「+α」が求められる§11.30 は、§11.10 の管理を適宜含めたうえで、文書の暗号化および適切なデジタル署名標準の使用といった追加措置を求めている。保護すべき期間は「作成時点から受領時点まで」である。
- 二項対立で捉えないクローズドとオープンの本質的な違いは「通信経路と権限を誰が管理しているか」にある。インターネットでは不特定多数の中継装置を経由するため、盗聴・改ざん・なりすましが構造的に内在する。しかしクローズドであっても内部脅威は残る。「クローズドだから安全」「オープンだから危険」という二項対立ではなく、それぞれの環境に潜むリスクを正確に理解し、適切な対策を講じること——リスクの本質を知ることが、適切な対策の第一歩となる。
これらのリスクはいずれも適切な対策——暗号化、ハッシュ検証・デジタル署名、PKIによる認証——によって大幅に低減可能である。現代のインターネットは、これらの技術を組み合わせることで、安全な通信インフラとして機能している。Part 11 がオープンシステムに対して暗号化とデジタル署名を求めているのも、同じ発想に立つものである。
参考・出典(一次情報源)
- eCFR「21 CFR Part 11 – Electronic Records; Electronic Signatures」
- eCFR「21 CFR §11.3 Definitions」((b)(4) Closed system/(b)(9) Open system)
- eCFR「21 CFR §11.10 Controls for closed systems」
- eCFR「21 CFR §11.30 Controls for open systems」
- eCFR「21 CFR §11.70 Signature/record linking」
- FDA「Part 11, Electronic Records; Electronic Signatures — Scope and Application」(2003年8月)
- NIST「SP 800-63B – Digital Identity Guidelines: Authentication and Lifecycle Management」
- NIST「SP 800-52 Rev.2 – Guidelines for the Selection, Configuration, and Use of TLS Implementations」
- NIST「FIPS 186-5 – Digital Signature Standard (DSS)」
- FDA「Guidance for Industry – Part 11, Electronic Records; Electronic Signatures — Scope and Application(PDF)」
- 厚生労働省「医薬品等の承認又は許可等に係る申請等における電磁的記録及び電子署名の利用について」(平成17年4月1日 薬食発第0401022号、ER/ES指針)