医療管理者がITセキュリティの勘所をつかむための入門書

前回記事の7,8章の詳細をまとめた記事になっています。セキュリティ不安のないツール導入へ。

医療管理者が知っておきたいITセキュリティの基本——クラウドかオンプレかより先に考えること

訪問看護師として働きながら、私は残薬管理アプリを個人開発しています。

開発を続けていると、職場の上司や管理者から、こんな言葉をもらうことがあります。

「クラウドって、個人情報が漏れないの？」
「やっぱりオンプレのほうが安全じゃないの？」

正直、この不安はよくわかります。

医療や介護の現場では、患者さんに関わる情報を扱います。だからこそ、「外部のサービスを使って本当に大丈夫なのか」と慎重になるのは、むしろ当然の感覚です。

ただ、その一方で、私は少し違和感も持っています。それは、

“クラウドだから危ない”

“オンプレだから安全”

という話に寄りすぎてしまうことです。

セキュリティとは、単に「どこに保存するか」ではなく、誰が、どの権限で、どの情報にアクセスできるかを設計することだと思っています。

この記事では、私が開発している残薬管理アプリの実装をもとに、医療ツールのセキュリティ設計がどのように実現されているかを解説します。

エンジニアでなくても理解できるように、できるだけ現場の言葉に置き換えながら書いていきます。

---

1. まず知っておきたい：セキュリティには「2種類」ある

医療現場でITが話題になると、「ファイアウォール」「VPN」「クラウド」などの言葉が出てきます。

でもこれらは、全部ひとまとめに「セキュリティ」と呼ばれているだけで、守っているものが違います。

大きく2つに分けられます。

ネットワークセキュリティ

→ 「そこまで来られるか」を守る

アプリケーションセキュリティ

→ 「来た人が中に入れるか」を守る

建物に例えると、こうなります。

【外の道路】

↓

【門・フェンス】← ネットワークセキュリティ

↓ 突破された

【玄関の鍵】← 認証（あなたは誰か確認）

↓ 解錠された

【部屋ごとの鍵】← 認可（どの部屋に入れるか）

↓

【防犯カメラ・入退室ログ】← 操作ログ（誰がいつ何をしたか記録）

どちらかだけ強くても、意味が薄い。

門を固くしても、玄関が無施錠なら誰でも入れます。

玄関を固くしても、部屋の鍵がなければ、入った人が何でも見られます。

医療現場の「クラウド怖い」という感覚は、主にネットワークへの不安です。でも実際に医療情報を守るために重要なのは、その先——アプリケーションの設計です。

---

2. 「よく聞く言葉」の正体

よく耳にするセキュリティ用語が、どちらの層の話なのかを整理しておきます。

ここで一つ、大事な話があります

IP制限は「このIPアドレス（場所）からしかアクセスできない」という制限です。自宅や職場の固定回線なら使えます。でも、スマートフォンのテザリングやカフェのWi-Fiはアクセスのたびにアドレスが変わるため、訪問看護師など移動を伴う職業のセキュリティ管理は、IP制限だけに頼ると運用が難しくなります。

より実用的なのは、多要素認証（MFA）です。

多要素認証とは、パスワードに加えて「スマートフォンに表示される6桁のコード」など、もう一つの確認手段を組み合わせる方法。あのめんどくさい2段階認証というやつです。どのネットワークから来ても有効で、パスワードが漏れただけでは侵入できない状態を作れます。

1年ほど前、中小の病院がサイバー攻撃を受けた事例がありました。その際に、多くの分析がされ問題が浮き彫りになりました。その病院は、パスワードでログインした後、誰でもそのパソコンからであればアクセスできる状態のまま放置されていたのです。

でも、これ、ほとんどの病院がそうではないですか？

idとパスワードは保存されており、エンターを押せば入れる仕様になっていませんか？

---

3. クラウドのネットワーク層は「誰が担うか」

このアプリは React + Supabase（データベース）+ Vercel（公開サーバー）という構成です。

ネットワーク層のセキュリティは、ほぼクラウドプロバイダー（クラウド上のサーバーやデータベースを提供・管理している会社。たとえば Supabase や AWS、Google Cloud など）が担ってくれています。

Supabase のデータベースはインターネットから直接アクセスできない場所にあります。Supabase の API を経由しないと、そもそも届かない設計です。

つまり「クラウドは怖い」の実態は多くの場合、設計が見えない、どこからでもアクセスできるんでしょうという不安 です。実際には、適切なクラウドサービスの方が、オンプレの社内サーバーよりも厳密にネットワーク分離されていることもあります。

怖いのはクラウドかオンプレかではなく、設計がされているかどうか です。

---

4. このアプリが実装したセキュリティ設計

ここからは、アプリケーション層——つまり設計次第で大きく変わる部分の話です。

残薬管理アプリで実装しているセキュリティは、5つの層に分かれています。

① 情報の最小化（個人情報を入力できない設計）

② 認証（誰がアクセスするか）

③ 認可（どのデータにアクセスできるか）

④ 操作ログ（誰が何をしたか）

⑤ 通信・ヘッダー（ブラウザ経由の攻撃を防ぐ）

---

① 情報の最小化——入力できない設計

セキュリティの一番の基本は、「守る情報を減らすこと」です。漏れたら困るデータは、最初から持たない。

このアプリに登録できる情報は、こうなっています。

登録できる情報：

- 利用者のニックネーム（「Aさん」「田◯さん宅」など）
- 薬の名前・残数・タイミング
- 受診予定日・医療機関名

登録しない情報：

- 利用者の氏名・住所・連絡先・生年月日
- 診断名・病名

単体で個人を特定できる情報を最初からシステムに存在させないのが最初の設計方針です。

複数の準個人情報で個人が特定されない程度に設計しようと考えているためニックネーム部分の運用も今構築中です。

データベースの定義レベルで、氏名・住所を入力するフィールドが存在しないようにしています。画面で禁止するより強い制約です。画面を迂回してAPIを直接叩いても、テーブルに存在しないカラムには何も入れられません。

---

② 認証——誰がアクセスするか

認証とは「あなたは誰ですか」を確認することです。
このアプリはメールアドレスとパスワードでログインします。ログインのコードはこうなっています。

ここで大切なのが、パスワードの保存方法です。

入力したパスワードそのものは、データベースには保存されません。

たとえば `password123` というパスワードを登録しても、データベースには `$2a$10$...` のような意味のわからない文字列として保存されます。

これは bcrypt という仕組みで変換されたもので、元のパスワードには戻せません。

ログインするときは、入力されたパスワードをもう一度同じ変換にかけて、保存されている文字列と一致するかを確認します。

つまり、管理者でもユーザーのパスワードを直接見ることはできません。万が一データベースの中身が見られても、パスワードは分かりません。

ログイン成功後は、JWT（JSON Web Token） というデジタル証明書が発行されます。以降のアクセスでは、このトークンを提示することで「ログイン済み」と判断されます。

---

③ 認可——誰がどのデータを見られるか

ここが最も重要な設計です。

「ログイン済み」イコール「全データ見放題」では困ります。

このアプリは複数の事業所が同じデータベースを共有します。A事業所のスタッフが、B事業所のデータを見られてはいけない。

③-1. 事業所ごとのデータ分離：RLS（行レベルセキュリティ）

Supabaseでは、データベーステーブル(PostgreSQLのテーブル)を窓口(REST API経由)で操作できます。

これは、API経由でデータを書き換えられる便利な仕組みですが、医療ツールとして使う場合は慎重な設計が必要です。画面上では見えないようにしていても、データベース側に制限がなければ、リクエストの作り方によって本来見えてはいけないデータにアクセスできてしまう可能性があるからです。

そこで使っているのが、PostgreSQLの RLS（Row Level Security） です。

RLSは、テーブルの行ごとに「誰が読めるか」「誰が追加・更新できるか」をデータベース側で定義できる仕組みです。

このアプリでは、全テーブルに `org_id`（事業所ID）を持たせ、ログイン中のユーザーが所属している事業所IDと、データの `org_id` が一致する場合だけ、そのデータを扱えるようにしています。

`USING` は、すでにあるデータを読む・更新する・削除するときの条件です。`WITH CHECK` は、新しくデータを追加したり、更新したりするときの条件です。

この2つを設定することで、

見るときも、自分の事業所のデータだけ。

作るときも、自分の事業所のデータとしてしか作れない。

という制約をかけています。

ここで重要なのは、事業所IDの判断をブラウザ側に任せていないことです。

たとえば、悪意のある人がブラウザから「自分の事業所IDは別の事業所です」とリクエストしても、それは採用されません。

`my_org_id()` が、ログイン中のユーザーIDをもとに、データベース側で所属事業所を確認します。

つまり、RLSは「画面で隠す」ための仕組みではありません。

データベースそのものに、

この人には、この事業所のデータしか渡さない

というルールを持たせる仕組みです。

SupabaseのようにREST APIでデータベースを扱う場合、このRLSを患者情報、薬剤情報、記録、スタッフ情報など、事業所ごとに分離すべき【すべて】のテーブルに確実に設定しておくことが重要になります。

私の設計書をSEの方に見ていただいた際に、ここを特に丁寧に設計しろと言われました。

③-2. 管理者だけが削除できる

スタッフには `admin`（管理者）と `staff`（一般）の2種類があります。削除操作は管理者のみ許可しています。これをロール管理と呼びます。

ブラウザ側でロールを書き換えても、データベース側の関数が実際のスタッフ情報を参照して判定します。「私は管理者です」と主張しても無効です。

---

④ 操作ログ——誰が何をしたか

医療現場では「誰がいつ何を変更したか」を追跡できることが重要です。

このアプリには `audit_logs` テーブルがあり、ログイン・薬の追加・残数の変更・削除などをすべて記録します。

ただ、ログを記録するだけでは不十分です。もし誰でもログを書き込めるなら、「誰が書いたか」を偽装できてしまいます。

このアプリでは、ログの書き込みをデータベース側の関数だけに限定しています。

さらに、`audit_logs` テーブルへの直接書き込み権限をデータベースレベルで剥奪しています。

ブラウザから「田中さんが操作した」と偽ってログを書き込もうとしても、物理的にできません。ログを書けるのはデータベースの関数だけです。

---

⑤ 通信・ヘッダー——ブラウザ経由の攻撃を防ぐ

画面を開いているだけで攻撃される可能性がある、というのがWebの現実です。

外部の悪意あるスクリプトを読み込まれたり、偽サイトに埋め込まれたりする攻撃に対して、セキュリティヘッダーで防衛しています。

サーバーからブラウザにヘッダーを渡すことで、制御を決めることができるのです。

---

5. 全体を図にすると

どこか一つが突破されても、次の層が守ります。

---

6. 既知の課題も正直に書く

完璧なシステムはありません。このアプリにも残っている課題があります。

認証トークンの保存場所

ログイン後の証明書（JWT）はブラウザのローカルストレージに保存されます（Supabase のデフォルト動作）。スクリプト攻撃でページに悪意あるコードを注入されると、証明書を盗まれる可能性があります。

セキュリティヘッダーで外部スクリプトの読み込みを制限することで軽減していますが、根本的な解決には別の実装が必要です。現在の対応水準で運用上のリスクは低いと判断していますが、今後の改善点として把握しています。

操作者名はログイン時の入力値

薬の残数を誰が更新したかを記録する項目は、ログイン画面で入力した名前がそのまま使われます。監査ログはデータベース側で本人確認していますが、各テーブルの「更新者」はクライアント側の入力値です。今後、スタッフ情報と統一していく予定の部分です。

---

7. 医療管理者として「何を確認すべきか」

ITツールを職場に導入するとき、「セキュリティは大丈夫ですか？」と聞くだけでは評価できません。

具体的に聞けることを整理しておきます。

データについて

- このシステムはどんな情報を保存しますか？（個人情報の範囲確認）
- 退職者のアカウントは、いつ・どうやって無効化できますか？
- 他の事業所や組織のデータと混在しませんか？

アクセス管理について

- スタッフごとに権限（見られる範囲）を変えられますか？
- ログイン方法に多要素認証（MFA）は使えますか？
- 誰がいつ何を操作したか、ログは残りますか？

運用について

- ログは改ざんできない仕組みになっていますか？
- データのバックアップはどのくらいの頻度で取られていますか？
- 万が一問題が起きたとき、誰に何をどう連絡すればいいですか？

「クラウドですか？オンプレですか？」より、これらの質問の方が実態に近い評価ができます。

---

8. 法令・ガイドライン

医療情報を扱うシステムには、法令上の義務があります。

個人情報保護法（改正 2022年）

- 個人情報を取得するときは利用目的を明示する義務がある

- 漏洩が発生した場合、72時間以内に個人情報保護委員会へ報告する義務がある（2022年改正で義務化）

- 影響を受けた本人への通知も必要

要配慮個人情報

病名・診断名・投薬歴・処方情報は「要配慮個人情報」に該当します。通常の個人情報より厳格な取り扱いが必要で、取得には本人の同意が原則必要です。

薬の名前を記録するシステムは、このカテゴリに触れる可能性があります。導入前に確認が必要な点です。

厚生労働省「医療情報システムの安全管理に関するガイドライン」

第6版（2023年）が最新です。電子保存の3原則を定めています。

---

9. まとめ——「運用でやりたいこと」を設計の言葉に変える

医療現場でのツール導入を進める中で、最も変わったのは要求の言語化です。

以前は「セキュリティが心配なので」で止まっていた会話が、今はこう言えるようになりました。

「退職したスタッフは即座にアクセス遮断したい。だから、アカウント管理は一元化して、無効化を1操作で完結できる設計にしてください」

「他の事業所のデータを誰も見られないようにしたい。だから、データベース側で組織ごとに分離してください」

「誰が残薬数を更新したか後で確認したい。だから、すべての更新操作をログに記録し、改ざんできない設計にしてください」

セキュリティは、クラウドかオンプレかで決まるものではありません。

誰が・どの権限で・どの情報に・どうアクセスできるかを設計すること。

そして「こういう運用をしたいから、設計はこうしてください」と言えるようになること。

それが、医療現場でのテクノロジー活用の第一歩だと思っています。

---

このアプリは現在試験運用中です。導入検討・フィードバックは X: @nurselog_ まで。

薬剤管理アプリLP

#看護師 #訪問看護 #医療DX #セキュリティ #個人開発 #ClaudeCode #Supabase #ICT活用 #在宅医療 #訪問看護師 #医療情報 #個人情報保護