はじめに：一度の誤送信で露呈するのは、従業員の問題ではなく権限の問題
ある積層造形工場に顧客から苦情が寄せられた。本来は当該プロジェクトの責任者だけに送付されるべきモデルファイルが、すでに異動していた従業員によって個人メールから外部の同業者へ転送されていた。振り返りの結果、企業は三つの事実を確認した。その従業員の旧プロジェクトへのアクセス権限は異動後も一度も回収されていなかったこと、ファイルのダウンロードには承認手続きが一切なかったこと、誰がいつどのファイルをダウンロードしたかについてシステム内にまったく記録がなかったことである。この三つが重なり、本来であれば阻止できた操作が、立証不能なデータ流出になった。
この種の事案は3Dプリンティング企業では珍しくない。業界では暗号化、秘密保持契約、透かしに注目が集まりがちだが、データの境界を実際に決めるのはアカウント権限体系である。誰が何を閲覧できるのか、誰がアクセスを承認したのか、アクセスによってどのような痕跡が残るのか。こうしたルールを実行可能な仕組みにすることは、秘密保持契約をさらに十件締結するよりも効果的である。
一、なぜ3Dプリンティング企業の権限管理は一般的な製造現場より難しいのか
3Dプリンティング企業のデータ形態は量産製造企業とは異なり、そのため権限設計には追加の複雑さがある。まず、データ粒度が細かい。一つの部品には、元の3Dモデル、修復後のメッシュファイル、スライスファイル、プロセスパラメータパッケージ、検査報告書、実物写真という六種類の資産が同時に存在する可能性があり、それぞれの機密レベルは異なる。顧客は通常、モデルを生産に使用することだけを許可し、モデルの二次修正や第三者への転送は許可しない。
次に、参加者が多い。社内の設計、工程、造形、後処理、品質検査、納品担当に加え、外注加工業者、設備メーカーのリモート保守担当者、顧客側の図面確認担当者、さらにはプロジェクトに一時的に参加する第三者検査機関も存在する。外部ロールごとに、アクセスが必要なデータ範囲、有効期間、実行可能な操作は異なるため、単一の社内アカウント体系でカバーしようとすれば必ず統制不能になる。
第三に、システムが分散している。モデルファイルはファイルサーバーまたはオブジェクトストレージにあり、スライスパラメータは設備メーカーのローカルソフトウェアにあり、検査データは測定機器またはCT装置の独立したワークステーションにあり、受注情報は業務システムにある。権限は四つのシステムでそれぞれ一部ずつ管理され、従業員が異動する際には四か所を変更しなければならない。どこか一か所でも漏れれば、脆弱な入口が残る。
二、ロール定義：まず組織構造をデータオブジェクトへ変換する
権限体系で最も陥りやすい誤りは、組織図をそのまま写すことである。職務は組織上の概念であり、権限はデータ上の概念である。両者の間には変換の層が必要となる。実行可能な方法は、先にデータオブジェクトの一覧を作成し、次にロールを定義し、最後に職務をロールへマッピングすることである。
データオブジェクトは部署単位ではなく、プロジェクト単位で編成することを推奨する。一つのプロジェクトディレクトリの配下に、モデル領域、工程領域、検査領域、納品領域という四つのサブスペースを置き、各スペースではさらに閲覧のみ、編集可能、ダウンロード可能、外部送信可能という四種類の操作を区別する。このように定義された権限にはプロジェクト境界が自然に組み込まれるため、Aプロジェクトで作業する従業員が、ついでにBプロジェクトのファイルを閲覧する事態を防げる。
ロール数は抑制すべきである。目安として、社内ロールは六～八種類に制限する。すなわち、プロジェクト責任者、設計エンジニア、工程エンジニア、生産オペレーター、品質検査、納品、システム管理者、監査担当者である。ロールが多すぎると、各ロールに何ができるかを誰も把握できなくなり、最終的には全員が管理者権限を申請する状態に陥る。監査担当者は必ず独立したロールとし、データを変更する権限を一切持たせてはならない。そうでなければ、ログを自ら削除できてしまう。
三、最小権限の原則：デフォルト拒否、必要に応じた一時的な権限付与
最小権限はスローガンではなく、検証可能な三つのルールによって支えられる。第一はデフォルト拒否である。新規アカウントは明示的な権限付与を受けるまで、いかなるプロジェクトも閲覧できない状態にする。多くのシステムでは初期設定が「全員閲覧可能」となっているが、これは3Dプリンティングの環境では顧客モデルを半公開にすることと同義である。
第二は、権限に期限を設定することである。通常の職務権限は四半期ごとに見直し、プロジェクト型の権限はプロジェクト終了日に紐付け、一時的な外部アクセスは日単位で設定する。権限の期限が切れた後は、誰かが閉鎖作業を覚えているのを待つのではなく、システムが自動的に回収し、プロジェクト責任者に確認通知を送る。第三は操作の分離である。ダウンロードと外部送信は二つの異なる権限とする。生産のためにファイルをダウンロードできることは、そのファイルを外部へ送信できることを意味しない。外部送信は別途承認を必須とし、証跡を残さなければならない。
高機密データには、二者承認の導入を推奨する。顧客の元モデルのエクスポート、プロセスパラメータパッケージ全体のエクスポート、しきい値を超える一括ダウンロードという三種類の操作については、二人目の確認後にのみ実行可能とする。二者ルールの価値は内部不正を防ぐことだけではなく、一人による誤操作の確率を下げ、事後に第二の証人を残せる点にある。
四、アカウントライフサイクル：入社・異動・退職の三段階管理
権限統制が崩れる頻発ポイントは人員の変動である。入社段階で行うべきことは、権限申請を文書化することである。プロジェクト責任者が必要なデータスペースと操作の一覧を提出し、承認後に管理者が設定を行い、設定結果を申請書へ記録して証跡とする。口頭による権限申請は禁止する。
異動段階は最も重要でありながら、最も見落とされやすい。正しい順序は、旧職務の権限を先に回収し、その後に新職務の権限を付与することであり、重ねて付与することではない。実務上より確実な方法は、異動当日にアカウントのすべてのプロジェクト権限を凍結し、新しい職務の責任者が改めて権限申請を提出することである。申請されていないスペースはすべて閲覧不可とする。過去のプロジェクトで引き続きその従業員の参加が必要な場合は、プロジェクトメンバーとして別途申請し、終了日を設定する。
退職段階では、同じ日に三つの事項を完了する必要がある。アカウントを削除せず無効化すること（ログとの関連性を保持するため）、プロジェクトメンバー資格を一括削除すること、外部送信権限と共有リンクをすべて失効させることである。アカウントを削除すると、ログ内の操作実行者との関連付けが壊れ、事後追跡ができなくなる。これは多くの企業が経験してきた失敗である。
五、操作証跡：ログは五つの問いに答えられなければならない
証跡を残す目的はログを保管することではなく、事後に事実を再構成できるようにすることである。適格なアクセスログは最低限、誰が、いつ、どのデータオブジェクトに対して、どのような操作を行い、結果がどうだったか、という問いに答えられなければならない。フィールド設計では、ユーザー識別子、タイムスタンプ、オブジェクト識別子、操作種別、結果ステータスに加え、工場内の端末からのアクセスと遠隔地からの異常アクセスを区別するため、アクセス元端末とネットワーク上の位置も記録すべきである。
ログ自体も改ざん防止でなければならない。書き込み後は変更・削除不可とし、管理者アカウントにも削除権限を与えない。保存期間は少なくとも顧客契約で定められた紛争時効を満たし、通常は十二か月以上の保存を推奨する。ログファイルについてもアクセス監査を実施し、誰がログを参照したか自体も記録しなければならない。
ログがあっても確認がなければ、ログがないのと同じである。三種類の自動アラートを設定することを推奨する。勤務時間外の大量ダウンロード、単一アカウントの一日当たりダウンロード量が過去の基準値の三倍を超えた場合、外部アカウントが未承認のプロジェクトスペースにアクセスした場合である。アラートを直ちに違反と断定する必要はないが、必ず営業日内に担当者が処理し、対応記録を残さなければならない。
六、外部アカウントと共有リンクの境界
顧客の図面確認担当者、外注加工業者、設備メーカーの保守担当者は、社内アカウント体系と混在させず、独立した名前空間の外部アカウントを使用すべきである。外部アカウントはデフォルトで明示的に共有されたオブジェクトにしかアクセスできず、プロジェクトのディレクトリ構造は見えないようにする。また、リンクから他のファイルパスを推測できないようにする。共有リンクには列挙不能なランダム識別子を使い、有効期限とアクセス回数の上限を紐付ける必要がある。
設備メーカーによるリモート保守は、最も見逃されやすい経路である。保守アカウントは通常、設備制御システムに対して高い権限を持っている。これが生産ネットワークのファイルシステムと接続されていれば、外部に対して権限体系を迂回する裏口を開けることに等しい。正しい方法は、保守接続を独立したネットワーク経路で行い、保守期間中のファイルエクスポート操作も承認と証跡の対象に含めることである。
七、導入チェックリスト
企業は以下の項目で自己点検を実施できる。新規アカウントはデフォルトでどのプロジェクトも閲覧できない状態になっているか。特定の従業員が現在保有するすべての権限を五分以内に一覧化できるか。すべての権限に有効期限が設定されているか。異動プロセスにおいて、回収前に付与する権限の重複が存在しないか。ダウンロードと外部送信は独立した二つの権限になっているか。ログにはアクセス元端末のフィールドが含まれ、削除不可能か。外部アカウントは社内アカウントから分離されているか。共有リンクには有効期限とアクセス回数の上限が設定されているか。退職当日に外部送信リンクは失効しているか。前四半期に実際に一度、権限の見直しを実施したか。十項目のうち三項目以上に答えられない場合、権限体系の再構築が必要である。
まとめ
3Dプリンティング企業におけるデータ資産の境界は、最終的には暗号化強度や秘密保持契約ではなく、アカウント権限体系によって定められる。職務をロールに変換し、ロールを期限付きのデータオブジェクトに紐付け、デフォルトポリシーを拒否に設定し、すべてのアクセスを監査可能な記録として残す。この四つを適切に実行すれば、大半のデータ流出事案は発生前に阻止でき、発生後にも明確な立証が可能となる。権限管理は一度限りの制度公布ではなく、四半期ごとの見直しを行い、プロジェクトの変化に合わせて継続的に最適化すべきエンジニアリングの仕組みである。