mcpField
H
hipaa-audit

hipaa-audit

github.com/briiirussellセキュリティ478321 回インストール1 日前に更新
リポジトリ

hipaa-audit について

hipaa-auditは、保護対象保健情報を扱うシステムを監査するチーム向けの技術的なエンジニアリングスキルです。HIPAAの各規則に沿って監査を整理し、セキュリティ規則の安全策に重点を置きます。コンプライアンスの判断は法律顧問とプライバシー責任者が担います。

主な機能

  1. 01HIPAA規則と安全策の確認
  2. 02PHIの範囲とデータフローの指針
  3. 03アクセス制御と暗号化の検査
  4. 04監査ログと完全性制御
  5. 05侵害範囲の特定に関する技術指針

活用シーン

  1. 01ePHIを保存・送信するサービスの監査
  2. 02患者記録への過剰なアクセスの特定
  3. 03リスク分析用の技術的証拠の準備
  4. 04侵害調査に向けたログの評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/briiirussell/cybersecurity-skills --skill hipaa-audit

インストール後、Claude Code で/hipaa-auditを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
findings-format.md
findings.schema.json
severity-calibration.md
to-sarif.mjs
validate-findings.mjs
verification.md

詳細

翻訳後に原文が更新されています。最新の内容は原文をご確認ください。

HIPAA 監査 — 医療保険の携行性と責任に関する法律

HIPAA は、米国の医療エコシステムにおける保護対象保健情報(PHI)の取り扱いを規定しています。PHI の範囲は多くの人が考えるより広いため、エンジニアリングの対象範囲も広くなります。患者の予約を記したカレンダーの予定は PHI です。また、患者がアクセスしたポータルで記録された IP アドレスも、健康状態と組み合わさることで PHI となる場合があります。

このスキルは、HIPAA の 4 つの規則を軸に構成されており、特にセキュリティ規則の 3 つの保護措置カテゴリ(管理的/物理的/技術的)を重視しています。エンジニアリングの作業が発生するのはこの領域です。プライバシー規則、侵害通知規則、HITECH は、その上に重ねて適用されます。

最終的なコンプライアンスの判断は、弁護士およびプライバシー責任者が行います。このスキルは技術的なエンジニアリング層を担います。

相互参照:しばしば重複する GDPR/CCPA に関連するプライバシー対応については privacy-engineering、アクセス制御と認証については iam-audit、保存時および転送時の暗号化の詳細については crypto-audit、鍵管理については secrets-audit、監査ログのエンジニアリングについては siem-detection、侵害対応については incident-triage と security-comms を参照してください。

適用範囲 — 対象者と PHI とは

誰が遵守しなければならないか
  • 対象事業体(CE) — 健康保険、医療情報交換機関、HIPAA で定義された取引に関連して電子的に医療情報を送信する医療提供者
  • 業務委託先(BA) — 対象事業体に代わって PHI を作成/受領/維持/送信するすべての者(PHI を保有するクラウドホスティング事業者、SaaS 分析サービス、EHR ベンダー、請求サービス、一部の弁護士やコンサルタントも含む)
  • BA の再委託先 — これも BA です。委託関係は連鎖し、各リンクは上位のリンクと BAA を締結する必要があります

BAA を締結せずに CE の PHI を扱うシステムは、取り扱いがどれほど安全であっても違反となります。

PHI/ePHI とは

PHI = CE または BA が保有もしくは送信する、個人を特定できる健康情報です。ePHI = 電子的な形式の PHI です。

HIPAA の 18 の識別子(セーフハーバー方式による匿名化リスト — すべて削除されていれば、データは PHI ではなくなります):

  1. 氏名
  2. 州より細かい地理的区分(番地、市、郡、ZIP コード — 人口が 20,000 人未満の場合は完全な ZIP コード。ほとんどの場合、先頭 3 桁は使用可能)
  3. 年より細かい日付(生年月日、入院日、退院日、死亡日)— 89 歳を超える個人については、年も集約する必要があります
  4. 電話番号
  5. ファクス番号
  6. メールアドレス
  7. 社会保障番号
  8. 医療記録番号
  9. 健康保険の加入者番号
  10. 口座番号
  11. 証明書番号/ライセンス番号
  12. 車両識別番号およびシリアル番号(ナンバープレートを含む)
  13. デバイス識別番号およびシリアル番号
  14. URL
  15. IP アドレス
  16. 生体識別子(指紋、音声)
  17. 顔全体が写った写真および同等の画像
  18. その他、個人を識別できる一意の番号、特性、またはコード

重要: セーフハーバー方式で 18 の識別子を削除することは、2 つある匿名化方法の 1 つです。もう 1 つは専門家による判定(再識別リスクが低いことを統計分析で確認する方法)です。匿名化されたデータは PHI ではありませんが、仮名化されたデータは引き続き PHI です(個人と仮名を結び付ける鍵が、どこかで引き続き保有されているためです)。

適用範囲を縮小するパターン

最も一般的な適用範囲の縮小策:

  • 収集するデータクラスを制限する — 生年月日が不要なら、収集しない、送信しない、保存しない
  • 規制当局が認める場合は内部で仮名化する。ただし、内部で使う仮名も ePHI である点に注意してください(対応表は CE/BA が保有しています)
  • 可能な限り BA 契約を締結するサービスを利用する — AWS、Google Cloud、Azure、Stripe Healthcare、および一部の分析ベンダーは BAA を締結しますが、多くの SaaS ツールは締結しません
  • PHI を受領しないことを契約上約束するサービスを利用する — 取り込み時にデータを除去する分析プラットフォームや、厳格な PII フィルタリングを備えたエラー報告サービスなど

セキュリティ規則 — 3 つの保護措置カテゴリ

管理的保護措置(プログラムレベル)

これらはポリシーおよびプログラムの管理策です。エンジニアリングチームは成果物を提供し、プライバシー責任者がプログラムを統括します。

  • §164.308(a)(1) セキュリティ管理プロセス — リスク分析(基盤となるもので、重大な変更時に再実施)、リスク管理、制裁ポリシー、情報システムのアクティビティレビュー
  • §164.308(a)(2) セキュリティ責任者の任命 — セキュリティ責任者を明確に指名
  • §164.308(a)(3) 従業員のセキュリティ — 認可/監督、退職手続き
  • §164.308(a)(4) 情報アクセス管理 — アクセスの認可、変更
  • §164.308(a)(5) セキュリティの認識向上とトレーニング — セキュリティに関する注意喚起、悪意のあるソフトウェアからの保護、ログインの監視、パスワード管理を含む
  • §164.308(a)(6) セキュリティインシデント手順 — incident-triage を参照
  • §164.308(a)(7) 緊急時対応計画 — バックアップ、災害復旧、緊急モードでの運用、テスト
  • §164.308(a)(8) 評価 — 技術面および非技術面の定期的な評価
  • §164.308(b)(1) 業務提携者との契約 — すべての業務提携者と BAA を締結

エンジニアリング監査のインプット: リスク分析用の証拠パッケージ(資産インベントリ、脅威モデル、管理策の一覧)、従業員セキュリティの記録(アクセスレビュー、入社/異動/退職の証拠)、トレーニングの修了記録。

物理的保護措置(データセンター/施設)

最新の SaaS では、物理的保護措置の大半はクラウドプロバイダーのコンプライアンス体制から継承されます(クラウドプロバイダーの BAA でカバーされます)。以下を確認してください。

  • §164.310(a) 施設アクセス管理 — ePHI が処理されるオフィススペースがある場合
  • §164.310(b) ワークステーションの使用 — ePHI にアクセスするワークステーションに関するポリシー
  • §164.310(c) ワークステーションのセキュリティ — それらのワークステーションの物理的なセキュリティ
  • §164.310(d) デバイスおよびメディアの管理 — 廃棄、メディアの再利用、アカウンタビリティ、データのバックアップおよび保存

エンジニアリング監査のインプット: クラウドプロバイダーの BAA が該当する物理的保護措置の義務をカバーしていることを確認します。ePHI を扱う従業員のノート PC について、ディスク暗号化とリモートワイプを確認します。

技術的保護措置(エンジニアリングが監査する領域)

このスキルが重点的に扱う領域です。

§164.312(a) アクセス制御
  • 一意のユーザー識別 — 必須です。ePHI にアクセスする各個人に一意の ID を割り当てます。共有アカウントは禁止です
  • 緊急時アクセス手順 — 緊急時に PHI にアクセスするためのブレークグラス経路を設け、ログに記録します
  • 自動ログオフ — 対応可能な項目です。アイドル状態のセッションを終了します
  • 暗号化および復号 — 対応可能な項目です。保存時の ePHI を暗号化します(実際には必須として扱ってください。OCR による執行からも、このことが強く示唆されます)

監査用 grep パターン:

  • PHI テーブルへの共有サービスアカウントからのアクセス:個人に紐づかないアカウントによる SELECT.*patient、SELECT.*encounter
  • セッションタイムアウトの欠如:明示的なタイムアウト設定のないセッション設定を検索
  • 保存時に暗号化されていない ePHI:データストアごとに、DB レベルとバケットレベルの暗号化を確認
§164.312(b) 監査管理策
  • ePHI を含むシステムのアクティビティを記録し、調査するハードウェア、ソフトウェア、手続き上の仕組み

実際には、ePHI に関わるすべての読み取り、書き込み、アクセス判断をログに記録します。ログは少なくとも 6 年間保存します(HIPAA の一般的な文書保存期間)。エンジニアリングでの実装については siem-detection を参照してください。

§164.312(c) 完全性
  • ePHI を認証する仕組み — ePHI が許可なく変更または破棄されていないことを検証します
  • 実際には対応可能な項目です — 重要な ePHI レコードに対するハッシュ/署名の管理策、不変ログストレージ
§164.312(d) 個人またはエンティティの認証
  • ePHI にアクセスする個人またはエンティティの身元を確認します
  • MFA はセキュリティルールの文面で明示的に必須とされているわけではありませんが、2013 年以降の執行および HHS のガイダンスでは、ePHI へのリモートアクセスには MFA を強く推奨しています。実質的に必須として扱ってください。新しい HHS のガイダンス(2024 年以降)では、MFA を明示的な要件とする方向に進んでいます

実装については iam-audit を参照してください。

§164.312(e) 伝送セキュリティ
  • 完全性管理策 — 実施可能な要件です。伝送中の ePHI を不適切な変更から保護します
  • 暗号化 — 文面上は実施可能な要件ですが、必須要件として扱ってください。ネットワークを経由するすべての ePHI に TLS 1.2 以降を使用します

crypto-audit を参照してください。

プライバシールール — PHI の取り扱い

プライバシールールは、PHI の使用と開示に関する規則を定めています。セキュリティルールが「保護すること」と定めているのに対し、プライバシールールは「特定の目的に限って使用できる」と定めています。

エンジニアリングに関係する項目:

  • 最小限必要な範囲の基準 — 治療以外の目的で PHI を使用または開示する場合、必要最小限の範囲に限ります。エンジニアリングでの実装方法:ロールベースのアクセス制御、クエリレベルでの範囲指定(患者テーブルから SELECT * しない)、呼び出し元が必要とするフィールドだけを返す API コントラクト
  • TPO の例外 — 治療、支払い、医療運営には承認が不要です。それ以外のほとんどの用途では必要です
  • 個人の権利 — アクセス権(GDPR の DSAR と同様 — 30 日以内の提供)、訂正を求める権利、開示記録の確認
  • プライバシー慣行通知 — 公開し、最初のやり取りの際に提示します

監査時の grep パターン:

  • 範囲が広すぎる PHI クエリ:SELECT \*.*patient、SELECT \*.*encounter、SELECT \*.*observation — ほぼ常に最小限必要な範囲の基準に違反します
  • 呼び出し元が特定のフィールドだけを必要としているのに、完全な患者記録を返す API エンドポイント
  • TPO に基づく根拠なしに PHI を受け取る分析プラットフォーム/監視ツール

侵害通知ルール

侵害とは、保護されていない PHI の不正な取得、アクセス、使用、または開示であり、PHI のセキュリティまたはプライバシーを損なうものです。「保護されていない」とは、HHS のガイダンスに従って暗号化されていないことを意味します(暗号化はセーフハーバーです)。

通知の期限:

通知先期限
影響を受けた個人不合理な遅延なく、発見から 60 暦日以内
保健福祉省(HHS / OCR)500 人以上に影響する侵害は発見から 60 日以内。500 人未満に影響する侵害は年次報告
メディア州または管轄区域内で 500 人を超える人に影響する侵害について、同じ 60 日以内
事業提携者から対象事業体へ不合理な遅延なく、60 日以内

「侵害」には不正アクセスも含まれ、データの持ち出しだけを指すものではありません。従業員が閲覧する必要のない記録を閲覧した場合、限定的な例外のいずれかに該当しない限り、これは侵害です。

エンジニアリング上の要点: 侵害の範囲を迅速に特定できること。監査ログ(セキュリティルール §164.312(b))が信頼できる情報源です。範囲の特定にかかる時間は、60 日の期限に直接影響します。

セーフハーバー: HHS が認める標準に従って PHI が暗号化されており、鍵も侵害されていない場合、不正取得が侵害に該当しない可能性があります。これは ePHI を保存時に包括的に暗号化する最も強い理由です。

incident-triage(対応)、security-comms(通知文案 — 法務レビューが必要)、breach-patterns(インシデント後のパターン抽出)を参照してください。

HITECH 層

HITECH(2009 年)は、ここで関係するいくつかの点で HIPAA を強化しました。

  • 多くのセキュリティルール違反について、BA に直接責任を負わせました(以前は CE のみが対象)
  • 民事金銭制裁を強化しました(段階制で、規定ごと・年ごとに最大 150 万ドル)
  • 侵害通知ルールを連邦法としました(一部の州法による複雑な規制を置き換え)
  • 患者が自身の PHI の電子コピーを入手する権利を強化しました

現代のエンジニアリング業務において、HITECH は、ePHI を取り扱う BA がセキュリティルールの大部分に直接従う必要があることを意味します。ベンダーは CE の陰に隠れることはできません。

監査チェックリスト

# HIPAA Audit Findings
## Entity: [name]
## Entity type: Covered Entity / Business Associate / Subcontractor
## Date: [date]
## Auditor: [name]

### Scope
- [ ] ePHI inventory complete (every data store containing PHI)
- [ ] Data flow diagrams for PHI transmission paths
- [ ] BAA in place with every BA (and BA's subcontractors where required)
- [ ] Cloud provider BAA on file (AWS / GCP / Azure / etc.)
- [ ] Risk analysis (§164.308(a)(1)(ii)(A)) current

### Administrative safeguards
| Subsection | Status | Findings |
|------------|--------|----------|
| Security Management Process | | |
| Assigned Security Responsibility | | |
| Workforce Security | | |
| Information Access Management | | |
| Security Awareness and Training | | |
| Security Incident Procedures | | |
| Contingency Plan | | |
| Evaluation | | |
| BA Contracts | | |

### Technical safeguards
| Subsection | Status | Findings |
|------------|--------|----------|
| Access Control — unique IDs | | |
| Access Control — emergency access | | |
| Access Control — automatic logoff | | |
| Access Control — encryption at rest | | |
| Audit Controls | | |
| Integrity | | |
| Person / Entity Authentication (MFA) | | |
| Transmission Security (encryption in transit) | | |

### Privacy Rule
- [ ] Minimum necessary applied in code (no SELECT * on PHI tables)
- [ ] Notice of Privacy Practices published and presented
- [ ] Individual access path implemented (30-day delivery)
- [ ] Amendment / accounting of disclosures process exists

### Breach response readiness
- [ ] Audit logs sufficient to scope a breach within 60-day clock
- [ ] Incident-response procedures tested
- [ ] Notification templates drafted (see security-comms)
- [ ] Encryption-as-safe-harbor verified across ePHI stores

### Findings detail
[Per finding: section reference, severity, location, evidence, remediation]

### Recommendations
[Prioritized]

owasp-audit に従った処置規則(修正/延期/リスク受容)。HIPAA におけるリスク受容は強く推奨されません。「受容したリスク」のほとんどは、残存リスクとして、補完的な管理策と再評価のトリガーとともに記録する必要があります。

一般的な監査で見られる指摘事項(実際の事例に基づく仮説)

  • BAAを締結していないベンダーのパイプラインにおけるPHI — Sentry、Datadog、Mixpanel、Segment、SlackがBAAなしでPHIを受け取っています(SentryにはBAAの締結方法があり、Datadogには医療向けサービスがあります。Mixpanelはデフォルトでは対応していません。各ベンダーのBAAに関する方針を確認してください)
  • 共有サービスアカウントによる一意のユーザーID要件への違反 — エンジニアリングチームが、PHIに臨時アクセスするために共有管理者アカウントを使用しています
  • PHIテーブルに対するSELECT * — 必要最小限の原則に違反しています。呼び出し元が必要とする項目が少ないにもかかわらず、APIシリアライザーがすべてのフィールドを返しています
  • 年齢範囲だけでよいのに生年月日を保存している — データ最小化に関する不備です
  • バックアップは暗号化されているが、鍵が同じ場所に保管されている — セーフハーバーの適用には、鍵の分離が条件となります
  • 本番環境からシードした非本番環境 — ステージングDBに、本番環境のダンプから取得した実際のPHIが含まれています
  • ePHIへのすべてのアクセス経路でMFAが強制されていない — 2024年以前の環境には不備が残っている可能性があります。現在はMFAを全面的に必須とする方向に進んでいます
  • 監査ログの保持期間が6年未満 — HIPAAの6年間の保持要件は、規則で求められる文書に適用され、コンプライアンスの証拠となる監査ログも含まれます
  • ePHIにアクセスするワークステーション/臨床アプリケーションに自動ログオフが設定されていない
  • BAの連鎖が途切れている — ベンダーの下請業者がePHIを取り扱っているにもかかわらず、BAがその下請業者と独自のBAAを締結していません

対応範囲

  • このスキルはエンジニアリング監査と準備を担います。対象事業体の該当性、BAとの関係、通知に関する最終判断は、プライバシー責任者/法律顧問が行います
  • HIPAAに違反するフローの構築には協力しません — BAAを締結していないベンダーへのPHIの送信、共有アカウントを使ったPHIへのアクセス、限定的に認められた場合を除き、エンドユーザーメッセージング技術(一般向けメール、SMS、チャット)を介したPHIの送信、許可を得ていないPHIのマーケティング利用
  • 情報漏えいが発生した場合:このスキルは漏えいの範囲を特定し、通知に必要なエンジニアリング上の情報を作成します。通知そのものはsecurity-commsと法律顧問を通じて行います
  • HIPAAの執行(OCR)は2013年以降拡大しており、規制の解釈も進化し続けています。このスキルの内容が最新のOCRガイダンスに追いついていない場合は、最新のOCRガイダンスが優先されます
  • 州法がより厳しい要件を課す場合があります(例:Texas HB 300、California CMIA)。州法が保護の水準で劣る場合に限り連邦法によって優先され、それ以外の場合は州の要件も適用されます
  • 遺伝情報にはGINAに基づく追加の保護があります — ここでは対応範囲外のため、専門的なガイダンスを参照してください

参考資料

  • HHS HIPAA Rules — hhs.gov/hipaa(規制本文、FAQ、OCRの和解合意)
  • HHS / OCR Audit Protocol — OCR監査人が使用するものです。自己評価のチェックリストとして役立ちます
  • HHS Security Risk Assessment Tool — 小規模・中規模の医療機関向けの無料ツールです
  • NIST SP 800-66 Rev. 2(2024年)— “Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide” — 最新の技術ガイダンスです
  • HITRUST CSF — HIPAA Security Ruleに対応する共通管理策フレームワークです。多くのBAがコンプライアンスの証拠としてHITRUST認証を取得します
  • OCR Resolution Agreements — 公開されている執行措置です。OCRが何を重大とみなすかを知るための先例として役立ちます
  • HHS Wall of Shame — 公開されている情報漏えいポータルです。業界の傾向を把握するのに役立ちます
  • 45 CFR Parts 160 and 164 — 規制本文そのものです
  • OCR Cybersecurity Newsletter — 四半期ごとのガイダンス更新
  • “HIPAA Plain & Simple” — Carolyn P. Hartley — 実務者向け参考資料

コメント