部門システム Web 基盤
セキュア実装ガイド

機能は実装できる。では「法規制を満たし、安全に使ってもらう」ために Web 基盤に何を実装し、どこまでやれば安心と言えるのか ——OWASP ASVS 5.0 のレベル2 を安心ラインに、3省2ガイドラインと検査業務の要件を、Java(Spring)・Angular の実装例で示す。

最終更新:2026年5月 / 対象:臨床検査(検査・細菌・病理)の部門システム Web サービス
医療DX シリーズ: 目次 ① 工程表 全体像 ② 法規制対応と技術要件 ③ 受注資格 ★ ④ セキュア実装(本編) データインテグリティ AI 活用移行FHIR/JLAC11FAQ・用語集

2 つの問いに分けて答える

何を実装するか機能ロジックの「上」に、認証・認可・監査ログ・データ保護・Web セキュリティを Web 基盤として組み込む。AWS(インフラ)が用意した暗号化基盤・WAF・監査基盤を、アプリが正しく使う実装が要る。
どこまでやれば安心か「安心」は主観なので、検証可能な基準に置き換える。OWASP ASVS のレベル2(L1+L2)を満たせば、客観的に「ここまでやった」と言える。これを安心ラインとする。
AWS の「上」にアプリ実装がある: KMS があっても、アプリが要配慮フィールドを暗号化しなければ守られない。WAF があっても、アプリの SQL インジェクション対策がなければ抜かれる。CloudTrail は AWS 操作の証跡で、「誰がどの患者の検査結果を見たか」はアプリが出す監査ログ。インフラは土台、本ガイドはその上のアプリ実装を扱う。

本資料は 2026 年 5 月時点の一般整理。実装例は方針を示すもので、実際の採用にあたっては各バージョンの公式ドキュメントと自組織のセキュリティ方針で検証すること。OWASP ASVS は 5.0.0(2025年5月)を参照。

凡例: L1基礎 L2標準(安心ライン) L3高保証 検査特有 ASVS V6該当章(例)

「どこまで」を ASVS のレベルで答える

OWASP ASVS(Application Security Verification Standard)5.0 は、Web アプリのセキュリティ要件を 17 章・約 350 項目に整理したチェックリスト。リスクに応じた 3 段階のレベルがある。

L1 基礎
第一層防御。最も重要なリスクに対処する、明確で少数の要件。
L2 標準
ほとんどのアプリが目指すべき水準。L1+L2 で全要件の約 70%。要配慮情報を扱う部門システムの安心ライン
L3 高保証
残り約 30%。多層防御や高難度の統制。大病院・公的調達・人命に関わる系。
安心の定義: 「ASVS の L1+L2 を全項目満たし、加えて 3省2GL のアプリ要件と検査業務特有を実装した」状態 = 客観的に「ここまでやった」と説明できる。これは法規制ガイドでやった網羅性の証明と同じ思想 ——主観でなくフレームワークで網羅し、チェックリストで証跡化する。「どこまで?」と問われたら「ASVS L2 を全部潰した、証跡はこれ」と即答できる。

過剰と不足の線引き

姿勢評価
機能が動いたら完了不足。認証・監査・データ保護の実装が抜け、法規制違反・漏えいリスクが残る。
全項目を L3 まで過剰。コストと工数が膨らみ、現場の開発が回らない。
要配慮コアは L2(一部 L3)、周辺は L1〜L2現実解。患者の検査データを扱う中核機能に L2 を確実に、リスクの高い箇所だけ L3 を足す。

実装カテゴリ一覧(このガイドの構成)

カテゴリ主な実装紐づく法規制・ASVS章
認証・セッション・認可二要素認証、セッションタイムアウト、RBAC、データ単位認可3省2GL運用編14章 / ASVS V6,V7,V8
入力・出力・Web入力検証、SQLi/XSS/CSRF 対策安全管理措置 / ASVS V1,V2,V3,V4
暗号・データ保護・通信フィールド暗号化、マスキング、TLS 強制個情法23条 / ASVS V11,V12,V14
ログ・API・設定・依存監査ログ、API 認証、依存脆弱性管理、秘密情報管理3省2GL / 事業者向けGL / ASVS V13,V15,V16
検査業務特有精度管理記録、トレーサビリティ、結果確定・訂正履歴、届出連携検体検査精度確保 / 感染症法

認証(ASVS V6)

L2ASVS V6

二要素認証(MFA)

なぜ
3省2GL 運用編14章 遵守事項⑤(努力規定)。令和9年度(2027年4月〜)に稼働する新規・更新システムは、原則として二要素認証の採用が望ましい。努力規定だが、要配慮情報を扱うため L2 として実装する。
実装例
Spring
// Spring Security 6.4+ の組み込みパスキー(WebAuthn)または TOTP
// 物理区画(検査室)運用なら ICカード+生体で「二要素相当」も可
http.webAuthn(w -> w.rpName("LIS").rpId("lis.example.jp")
                    .allowedOrigins("https://lis.example.jp"));
Angular
// WebAuthn は navigator.credentials.create/get を使用
// MFA 入力画面は通常のフォーム + ワンタイムコード検証 API 呼び出し
L1ASVS V6

パスワードの安全な保管とポリシー

なぜ
平文・可逆保管は漏えい時に致命的。ハッシュ(ソルト付き)保管と、長さ重視のポリシー、漏えいパスワードの拒否。
実装例
Spring
@Bean PasswordEncoder encoder() {
  return new BCryptPasswordEncoder(12); // または Argon2PasswordEncoder
}
// 推定不可・運用担当者もパスワードを復元できない(3省2GL 14章⑥)
L2ASVS V6

アカウントロックアウト(ブルートフォース対策)

なぜ
総当たり攻撃の防止。一定回数の失敗でロック、または指数的バックオフ。
実装例
Spring
// AuthenticationFailureHandler で失敗回数を記録、閾値でロック
// アカウント列挙を防ぐため、エラーメッセージは一律にする

セッション管理(ASVS V7)

L2ASVS V7

セッションタイムアウト(共有端末の自動ログアウト)

なぜ
検査室・ナースステーションの共有端末では、放置されたセッションからの不正閲覧を防ぐ。アイドルと絶対の両方のタイムアウト。
実装例
Spring
server.servlet.session.timeout=15m   # アイドルタイムアウト
# Angular 側でも操作監視 → 一定時間で自動ログアウト + 警告ダイアログ
L1ASVS V7

セッション ID 再生成・Cookie 属性

なぜ
ログイン時のセッション ID 再生成(固定化攻撃対策)、ログアウトで確実に無効化。Cookie は盗難・改ざんを防ぐ属性を付与。
実装例
Spring
http.sessionManagement(s -> s.sessionFixation().newSession());
server.servlet.session.cookie.http-only=true
server.servlet.session.cookie.secure=true
server.servlet.session.cookie.same-site=strict

認可(ASVS V8)

L1ASVS V8

サーバ側での認可チェック(全リクエスト)

なぜ
画面の出し分けだけでは不十分。すべての API でサーバ側が権限を検証する。クライアントの制御は迂回されうる。
実装例
Spring
@PreAuthorize("hasRole('TECHNOLOGIST')")
public Result confirmResult(Long id) { ... }
// メソッドセキュリティを有効化:@EnableMethodSecurity
L2ASVS V8

RBAC(職種別)と結果確定権限・代行入力の識別

なぜ
医師・臨床検査技師・事務で権限を分ける。検査結果の確定権限と代行入力時の代行者識別(3省2GL 運用編14章⑧、記録確定・真正性)。検体検査の精度確保とも結びつく。
実装例
Spring
@PreAuthorize("hasRole('DOCTOR') and @resultPolicy.canConfirm(#id, principal)")
// 代行入力は actor(操作者)と subject(責任者)を別々に記録
L2ASVS V8

データ単位の認可(IDOR 対策)

なぜ
URL の ID を書き換えて他患者・他部門のデータを閲覧できてはならない。リソース所有権をサーバ側で必ず検証する。
実装例
Spring
// id だけでなく「その利用者がアクセスしてよいか」を where 句に含める
repo.findByIdAndDepartment(id, currentUser.getDepartment())
    .orElseThrow(AccessDeniedException::new);

入力検証・SQL インジェクション(ASVS V1,V2)

L1ASVS V1,V2

サーバ側入力検証 + SQL インジェクション対策

なぜ
クライアント検証は迂回される。サーバで型・範囲・必須を検証。SQL は文字列連結せずプレースホルダ(バインド)を使う。
実装例
Spring
// Bean Validation
public record OrderReq(@NotNull Long patientId, @Size(max=50) String memo) {}
@PostMapping void create(@Valid @RequestBody OrderReq r) { ... }
// SQLi 対策:JPA / @Query はパラメータバインド。文字列連結は禁止
@Query("select r from Result r where r.code = :code")

XSS・CSRF(ASVS V3 Web Frontend)

L1ASVS V3

XSS(クロスサイトスクリプティング)対策

なぜ
検査コメント等にスクリプトを埋め込まれ、他利用者のブラウザで実行されるのを防ぐ。出力時のエスケープが基本。
実装例
Angular
// Angular は {{ }} 補間とプロパティバインドで自動エスケープ
// 危険:bypassSecurityTrustHtml() の安易な使用は禁止
// HTML を表示するなら DomSanitizer で必ずサニタイズ
L1ASVS V3

CSRF(クロスサイトリクエストフォージェリ)対策

なぜ
利用者の意図しないリクエスト(結果確定・削除など)を第三者サイトから送られるのを防ぐ。
実装例
Spring
// Spring Security は CSRF 保護がデフォルト有効
// SPA は CookieCsrfTokenRepository でトークンを Cookie 配布
Angular
// provideHttpClient(withXsrfConfiguration({
//   cookieName: 'XSRF-TOKEN', headerName: 'X-XSRF-TOKEN' }))
// XSRF-TOKEN Cookie を読み X-XSRF-TOKEN ヘッダで自動送信
L2ASVS V4,V5

SSRF・ファイルアップロード・ビジネスロジック検証

なぜ
外部連携(届出・参照系)の URL を悪用した SSRF、アップロードファイルのウイルス・型偽装、業務ルールの逸脱(マイナス値・不正な状態遷移)を防ぐ。
実装例
Spring
// 外部リクエスト先は許可リストで限定(任意URL禁止)
// アップロードは MIME・拡張子・サイズ検証 + ウイルススキャン
// 状態遷移は enum + ガード条件でサーバ検証

データ保護(ASVS V14)

L2ASVS V14

要配慮フィールドの暗号化

なぜ
個情法23条(安全管理措置)。検査結果・病理診断・感染症情報は要配慮個人情報。DB 全体暗号化(AWS の保存時暗号化)に加え、特に機微なフィールドはアプリ側で暗号化する選択肢。
実装例
Spring
// JPA AttributeConverter でフィールド暗号化(AES-GCM)
@Convert(converter = EncryptedStringConverter.class)
private String diagnosis;
// 鍵は KMS / Secrets Manager 管理。コードにハードコードしない
L2ASVS V14

画面マスキング・ログへの PII 出力防止

なぜ
権限や場面に応じて要配慮情報を伏せる。ログ・エラー・URL クエリに患者情報を出さない(ログ自体が漏えい経路になる)。
実装例
Spring
// ログ出力時に PII をマスクするフィルタ(logback)
// 患者 ID は URL クエリでなくパス or ボディ、ログにはハッシュ/連番

暗号・鍵管理(ASVS V11)

L2ASVS V11

鍵管理とアルゴリズム選定

なぜ
弱いアルゴリズム・固定鍵・コード内の鍵を避ける。鍵のローテーション、廃棄時の暗号学的消去(鍵削除)。
実装例
Spring
// AES-256-GCM 等の標準アルゴリズム。鍵は AWS KMS / CloudHSM
// 自前で暗号方式を発明しない(標準ライブラリを使う)

通信(ASVS V12)

L1ASVS V12

TLS 強制・HSTS

なぜ
全通信を TLS 1.2 以上で暗号化。HTTP は HTTPS にリダイレクト、HSTS で常時 HTTPS を強制。内部通信(マイクロサービス間)も TLS。
実装例
Spring
http.requiresChannel(c -> c.anyRequest().requiresSecure());
http.headers(h -> h.httpStrictTransportSecurity(hsts -> hsts.maxAgeInSeconds(31536000)));

監査ログ・エラー処理(ASVS V16)

L2ASVS V16

監査ログ(誰が・いつ・どの患者の・何を)

なぜ
3省2GL のアクセス証跡要件。漏えい時の事実調査・保守作業ログにも使う。患者単位のアクセスを時系列で追える形で残す。
実装例
Spring
// AOP @Around または HandlerInterceptor で操作を記録
// 構造化ログ(JSON)+ MDC で相関ID。actor / action / patientRef / timestamp
// ログは改ざん防止(S3 Object Lock 等の WORM 保管へ転送)
L1ASVS V16

エラーで内部情報を漏らさない

なぜ
スタックトレース・SQL・内部パスを画面に出すと攻撃の手がかりになる。本番では汎用エラー、詳細はサーバログのみ。
実装例
Spring
@ControllerAdvice + @ExceptionHandler で一律のエラー応答
server.error.include-stacktrace=never
server.error.include-message=never  # 本番

API(ASVS V4)

L2ASVS V4

API 認証・レート制限・過剰データ露出の防止

なぜ
電子カルテ・他部門との連携 API は、トークン認証で利用範囲を限定し、レート制限で乱用を防ぐ。レスポンスに不要なフィールドを含めない。電子カルテ連携は FHIR 等の標準形式で入出力する(標準規格対応)。
実装例
Spring
// OAuth2 Resource Server(JWT 検証)
http.oauth2ResourceServer(o -> o.jwt(Customizer.withDefaults()));
// レート制限:Resilience4j / API Gateway
// レスポンスは DTO で必要項目だけ返す(エンティティ直返し禁止)

設定・依存・セキュアコーディング(ASVS V13,V15)

L2ASVS V15

依存ライブラリの脆弱性管理(SCA)

なぜ
事業者向けGL の管理策。既知脆弱性のあるライブラリの混入を継続的に検知し、パッチを適用する。SBOM の整備。
実装例
Spring
// OWASP Dependency-Check(Maven/Gradle plugin)/ Snyk を CI に組込み
// AWS Inspector で SBOM(CycloneDX/SPDX)出力
L1ASVS V13

セキュリティヘッダー・秘密情報・本番設定

なぜ
CSP・X-Content-Type-Options 等のヘッダー、秘密情報のハードコード禁止、本番でのデバッグ・詳細エラー無効化。
実装例
Spring
// セキュリティヘッダー:CSP, X-Frame-Options, X-Content-Type-Options
http.headers(h -> h.contentSecurityPolicy(c -> c.policyDirectives("default-src 'self'")));
// 秘密情報は Secrets Manager / 環境変数。application.yml に平文で書かない

可用性・BCP・保存期間(ASVS V1 / 経営管理編)

L2経営管理編

障害対応・冪等性・ログの保存期間

なぜ
3省2GL は CIA の「可用性」と BCP を求める(経営管理編・企画管理編)。検査システムは止まると診療が止まる。インフラ(Multi-AZ 等)に加え、アプリ層でも障害に耐える実装が要る。監査ログ・記録は法定保存年限を満たす期間で保持する。
実装の要点
Spring
// ヘルスチェック(liveness/readiness):Spring Boot Actuator
// グレースフルシャットダウン:server.shutdown=graceful
// 再送に耐える冪等性(重複オーダー防止):冪等キー + 一意制約
// 依存先障害のタイムアウト・サーキットブレーカー:Resilience4j
// ログ・記録は保存年限(診療録5年 等)をライフサイクルで管理
検査・細菌・病理の固有要件: 一般的な Web セキュリティに加え、検体検査の精度確保(医療法・施行規則)と感染症法が、システムに特有の実装を求める。これらは ASVS の枠の外側で、医療ドメインとして上乗せする。
検査特有重要度:高

精度管理記録の保持・改ざん防止

なぜ
検体検査の精度確保(医療法15条の2・施行規則9条の7の2)。内部精度管理・外部精度管理調査・標準作業書・作業日誌を、改ざん不能で保持する。
実装の要点
確定記録は WORM 保管(S3 Object Lock コンプライアンスモード)。作業日誌は後追い一括入力を防ぐタイムスタンプ強制。SOP はバージョニングで版管理。
検査特有重要度:高

トレーサビリティ(試薬ロット・装置・校正)

なぜ
どの検査結果が、どの装置で、どの試薬ロットで、いつ出されたかを追える。再検査・リコール時の特定に必須。
実装の要点
分析装置との連携 I/F でロット・校正情報を欠落なく取り込む。結果レコードに装置・ロット・実施者・時刻を紐づけて記録。
検査特有重要度:高

結果の確定・訂正履歴(真正性)

なぜ
電子保存の三原則(真正性)。確定後の結果を誰が・いつ・なぜ訂正したかを残し、訂正前後を追えるようにする。確定操作の承認、代行入力の識別。
実装の要点
結果は上書きでなくバージョン管理(イミュータブルな履歴)。訂正理由を必須入力、確定者と訂正者を別々に記録。
細菌・微生物重要度:高

パニック値アラート・感染症届出データ連携

なぜ
救急パニック値の即時通知(完全性・可用性が機密性に優先する場面)。感染症法第12条の届出対象を検出した際の、正確な届出データ生成と安全な連携。
実装の要点
パニック値は確実な通知経路(フェイルセーフ)。届出データ連携は暗号化された限定経路(API Gateway+TLS、必要に応じ PrivateLink/VPN)と連携証跡。届出の最終判断は医師で、システムは支援に留める。
ABOUT

本シリーズは、医療情報システムの開発・クラウド化を手がける X Harumi が、公的な一次資料を根拠条項まで遡って再整理したものです。AI 活用支援・業務効率化・DX 推進・システム開発を提供しています。

最終更新:2026-05-25 / 次回レビュー目安:2026-08-31 / © X Harumi