技術的管理策34項目の読み方

技術的管理策は34項目。組織的管理策（37項目）に次ぐ規模で、93管理策の3分の1以上がここにあります。そして、医療SaaSを開発・運用している事業者にとっては、最も「既にやっていること」が多い領域でもあります。

ここが他のテーマと違うのは、必要な対策の大半が既に実装されているケースが多いことです。多要素認証も、ディスク暗号化も、依存ライブラリの脆弱性スキャンも、CI/CDでのテストも、まともなエンジニアリング組織なら既に動いている。にもかかわらずISMS構築で時間を取られるのは、「やっていること」と「規格が求めること」を突き合わせ、記録として取り出せる形にする作業が残っているからです。

本記事では、34項目を6つのグループに整理し、それぞれ何を求めているのか、医療SaaSの文脈で何を実装・記録すべきかを書きます。全体像は 附属書A 2022年版｜93管理策と4テーマの全体像 をご覧ください。

免責：本記事は一般的な情報提供です。管理策の題名・要求の本文は規格の正文に記載されています。本記事では著作権に配慮し、逐語の引用はせず、要求の趣旨を当社の言葉で説明しています。実際の適用判断は ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料に基づいて行ってください。

34項目を6つのグループで捉える

このうち、ヘルスケア事業者にとって重心が置かれるのは①④⑥です。医療情報を扱うサービスでは、「誰がアクセスできるか」「誰が実際にアクセスしたか」「そのシステムはどう作られたか」の3点が、取引先から最も具体的に問われます。

アクセス制御と認証：医療情報の説明責任の土台

このグループには、利用者端末の管理、特権アクセス権、情報へのアクセス制限、ソースコードへのアクセス、セキュアな認証、特権的ユーティリティプログラムの利用が含まれます。方針レベルの要求は組織的管理策側にあり、ここは実装の話です。

医療SaaSで押さえるべき論点を挙げます。

特権IDの扱いが最大の焦点です。 本番データベースに接続できるアカウント、クラウドコンソールの管理者権限、顧客テナントに横断アクセスできる運用管理画面。これらは日常的に使うものではないため、次の設計にしておくと説明が楽になります。

• 常時付与ではなく、必要時に申請・承認を経て一時的に付与する
• 付与と返却の記録が自動的に残る
• 特権操作のログを、権限を持たない第三者が定期レビューする
• 個人に紐づかない共用アカウントを作らない（作る場合は利用記録で個人を特定できるようにする）

顧客テナントへのアクセスは別扱いにしてください。 医療機関の本番データに自社の運用担当者が入れる構成は、サポート上必要である一方、医療機関から最も厳しく見られる部分です。「誰が・いつ・どの医療機関のデータに・何の目的で」入ったかを記録し、必要なら顧客に開示できる状態にしておくことが、取引条件として求められるケースがあります。マルチテナント固有の論点は 医療SaaSのISMS｜マルチテナントのリスク評価 で扱います。

ソースコードへのアクセス制限も見落とされがちです。リポジトリの権限、フォークの可否、退職者のアクセス削除、CI/CDに渡している認証情報の管理。ソースコードには接続情報やビジネスロジックが含まれるため、情報資産として台帳に載せておくべき対象です。

AIエージェントやMCP経由でシステムに権限を渡す構成を取っている場合は、その権限設計も同じ枠組みで評価する必要があります。MCPの権限設計 を参照してください。

脆弱性と構成管理：頻度と記録がすべて

マルウェアからの保護、技術的脆弱性の管理、構成管理、運用システムへのソフトウェア導入、容量・能力の管理がこのグループです。

技術的脆弱性の管理は、審査で具体的に聞かれる代表格です。求められているのは「脆弱性がないこと」ではなく、脆弱性情報を得て、自社への影響を評価し、対応を決め、実行し、記録する仕組みがあることです。

「対応しない」という判断も記録に残してください。 外部から到達できない内部ツールの中程度の脆弱性を次回定期更新まで据え置く、という判断は合理的です。ただしそれは判断であって放置ではないので、判断した記録が要ります。ここが空白だと、「管理していない」と見なされます。

VPN機器やネットワーク境界装置の脆弱性は、医療分野で実際に被害の起点になってきた領域です。この論点は VPN機器の脆弱性対策 で扱っています。

構成管理では、ベースラインの定義が要求されます。サーバ、クラウドリソース、従業者端末について「あるべき設定」を定め、そこからのずれを検知する仕組みです。IaCで構成を管理し、ドリフト検知を入れていれば、その仕組み自体が説明になります。手作業で本番環境を変更している箇所が残っているなら、そこが弱点になります。

データ保護のライフサイクル：暗号・バックアップ・消去

情報の削除、データマスキング、情報漏えい防止、暗号の利用、バックアップ、冗長化、テスト情報の保護がこのグループです。医療情報を扱う事業者では、ここが3省2ガイドラインとの重なりが大きい領域になります。

暗号の利用で求められるのは、暗号を使うこと自体より方針と鍵管理です。どの情報にどの方式を使うか、鍵をどこで生成し、どう保管し、いつ更新し、誰がアクセスできるか。クラウドのマネージドな鍵管理サービスを使っているなら、その設定と権限が説明になります。「TLSを使っています」だけでは要求の半分しか満たしていません。

バックアップと冗長化では、設計より復旧試験の記録が問われます。物理的管理策の項でも触れましたが、RPO/RTOを宣言していて復元を試したことがない状態は指摘の対象です。年1回、実際にバックアップから復元して所要時間を測り、記録する。これは審査対策であると同時に、医療機関への提案資料としてそのまま使えます。

テスト情報の保護は、医療SaaSで最も実務的に重い項目かもしれません。本番の患者データをそのまま検証環境にコピーする運用は、規格の観点でも3省2ガイドラインの観点でも説明が難しくなります。取り得る選択肢は次のとおりです。

現実には3つを組み合わせることになります。重要なのは、どの場面でどれを使うかを決めて文書化すること。「基本は合成データ、障害調査時のみ承認を経て本番データを限定利用し、調査完了後に消去する」という運用が書けていれば、この管理策は説明できます。

情報の削除も忘れがちです。顧客が解約したときの医療情報の消去、保存期間を過ぎたログの削除、退職者端末の初期化。契約で消去期限を約束しているなら、実行できる仕組みと記録が要ります。

ログと監視：取得より「見ていること」が問われる

ログ取得、活動の監視、クロックの同期、監査時の情報システムの保護がこのグループです。

技術的には多くの組織が既にログを取っています。問題は3点です。

1. 何を取るかが方針として定まっていない

「取れるものは全部」ではコストが膨らみ、肝心なものが埋もれます。最低限、次は取得対象として明記してください。

• 認証の成功・失敗（とくに特権アカウント）
• 権限の付与・変更・削除
• 医療情報へのアクセス（参照・更新・出力・削除）
• 管理操作（設定変更、デプロイ、データベースへの直接操作）
• セキュリティ機能の停止・変更

2. 保存期間が決まっていない

インシデントは発覚までに時間がかかります。3か月しか保存していないと、半年前の侵入を追跡できません。医療情報へのアクセスログについては、契約やガイドラインで期間が要求される場合があるため、契約要求 → 保存期間 → ストレージ設計の順で決めます。

3. レビューしていない

最も多い不備です。ログを取得していても、誰も見ていないなら検知の管理策として機能していません。すべてを人が見る必要はなく、アラート設計（自動検知）＋ 定期レビュー（人による抜き取り） の二段構えで足ります。月次で「今月のアラート件数と対応結果」を1ページにまとめる運用にすれば、記録としても成立します。

クロックの同期は地味ですが重要です。複数システムのログを突き合わせるとき、時刻がずれていると因果関係を追えません。NTPの設定とタイムゾーンの統一を確認し、設定を記録しておいてください。

ログの設計は医療機関側でも同じ論点になります。責任共有モデルで考えるAI電子カルテのセキュリティ設計 と 3省2ガイドラインとは をあわせて参照すると、どこまでを自社が持つべきかが整理できます。

ネットワークとセキュアな開発

ネットワーク

ネットワークのセキュリティ、ネットワークサービスのセキュリティ、ネットワークの分離、ウェブフィルタリングがこのグループです。クラウド前提の構成では、VPC/サブネットの設計、セキュリティグループの設定、外部公開エンドポイントの一覧、WAFの有無が説明の中心になります。

ネットワーク構成図を最新化しておくことが最も効率的な準備です。審査でも顧客のセキュリティチェックシートでも同じ図を使えます。図には、外部との接点（インターネットからの入口、外部APIへの出口）、医療情報が保存される領域、管理アクセスの経路を明示してください。

マルチテナントSaaSであれば、テナント間の分離をネットワーク層・アプリケーション層のどちらで担保しているかが問われます。アプリケーション層でのテナントID分離のみなら、その実装が正しいことを示すテストが必要になります。

セキュアな開発

このグループは項目数が多く、開発ライフサイクル、アプリケーションのセキュリティ要件、セキュアなアーキテクチャと設計原則、セキュアコーディング、開発・受入時のテスト、外部委託開発、開発・テスト・本番環境の分離、変更管理が含まれます。

既存の開発プロセスがあるなら、ゼロから作るのではなく、既存プロセスを規格の言葉で記述し直すのが正解です。多くの組織で既に動いているものを列挙すると次のようになります。

右列が実際の作業です。 左列が既にあるなら、追加作業は思うほど多くありません。設計段階からセキュリティを織り込む考え方は セキュリティ・バイ・デザイン で扱っています。

生成AIを組み込んだ機能を開発している場合、プロンプトインジェクションや学習データへの医療情報混入といった、従来の脆弱性分類に収まらない論点が加わります。医療機関の生成AI利用｜法的・セキュリティガイド もあわせてご覧ください。

まとめ

1. 34項目は6グループに収束する。ヘルスケアでの重心はアクセス制御・ログ・セキュアな開発
2. 特権IDは常時付与をやめ、申請・承認・記録の形にする。顧客テナントへのアクセスは別枠で記録する
3. 脆弱性管理で問われるのは「穴がないこと」ではなく評価・決定・実行・記録の仕組み。「対応しない」判断も記録する
4. バックアップは設計より復旧試験の記録。年1回の実施でよいので必ず残す
5. テスト情報は合成データ・マスキング・限定利用の使い分けを文書化する。本番データの無条件コピーは説明が難しい
6. ログは取得より保存期間とレビュー。アラート設計＋定期レビューの二段構えで、月次1ページの記録にする
7. セキュアな開発は既存プロセスを規格の言葉で記述し直すのが近道。ゼロから作らない

ポテックは、ヘルスケア領域に特化してISMS認証取得を支援しています。技術的管理策は、既存の開発・運用実態をどう文書と記録に落とすかが勝負です。エンジニアリングの実務を理解したうえで、既にやっていることを規格の要求に接続する形で整理を進められます。

支援内容と料金は ISMS認証取得支援サービス をご覧ください。個別のご相談は お問い合わせ から承ります。

全体像は ISMS（ISO/IEC 27001）とは｜ヘルスケア企業のための完全ガイド、採否の記載方法は 適用宣言書（SoA）の書き方、組織側の管理策は 組織的管理策37項目の読み方 をご覧ください。

参考・出典

• 情報マネジメントシステム認定センター（ISMS-AC）
• ISO/IEC 27001 Information security management systems｜ISO
• ISO/IEC 27002 Information security controls｜ISO
• 医療情報システムの安全管理に関するガイドライン｜厚生労働省
• 注意喚起｜JPCERT コーディネーションセンター
• 情報処理推進機構（IPA）

※管理策の解釈、および適用除外の可否は、規格の改定や審査機関の運用によって変わり得ます。最新の取扱いは規格本文および認定機関・審査機関の公表資料をご確認ください。