4.7. 情報の取り扱いの標準

4.7.1. 概要

この文書では, Webサービスにおける情報の取り扱いの標準を規定する.

4.7.2. 情報のレベル

情報のレベルの標準level-infomation で規定している.

4.7.3. 機密情報を扱うサービスの新規開始

レベルA,B,Cの機密情報を扱うサービスの新規開始を検討する場合, 情報セキュリティ委員会への報告を行なわなければならない.

4.7.4. 機密情報の保存時の暗号化

サービスは, レベルA,Bの機密情報は暗号化して保管しなければならない. ただし, ユーザの検索などに利用する情報については漏洩のリスクを考慮した上で暗号化しなくてもよい.

パスワードについては パスワードの標準 で暗号化の方法を定める.

その他の機密情報については, 情報の暗号化の標準 で暗号化の方法を定める.

4.7.4.1. 暗号化方式の変更への対応

データベースに格納する機密情報の暗号化の方式は, 暗号が安全でなくなった場合などに変更される可能性がある. サービスの開発者は, サービスを暗号化方式の変更に対応可能にしなければならない.

4.7.5. 機密情報の通信の暗号化

サービスは, レベルA,Bの機密情報は暗号化による保護を行なって通信しなければならない. ただし, 通信経路が社内ネットワークに限定される場合には, 保護することを推奨するが保護を行なわなくてもよい.

レベルCの情報についても, 暗号化による保護を行なって通信することを推奨する.

4.7.6. 機密情報へのアクセス権限管理とアクセスログの取得

サービスは, 以下の情報を扱う場合に情報へのアクセス権限管理とアクセスログの取得を行なわなければならない. システム化されていないやりとりについても記録を残さなければならない.

  • レベルA,B,Cの情報
  • 大量のレベルDの情報

4.7.6.1. アクセス権限管理

サービスの開発者は, 情報へのアクセス権限を管理できるように実装しなければならない.

  • 利用者アカウントに対しパスワードないしそれに代わる保護を提供しなければならない.
  • 後述のアクセスログを取得できなければならない.
  • 管理者が, 利用者の追加/削除が行なえなければならない.
  • 管理者が, 利用者のアクセス可能な情報を設定できなければならない (例: ユーザa は 情報Aについて閲覧のみ可能. 情報Bについては閲覧/登録/変更/削除が可能). ただし, あまりに細かい設定を可能にしても管理が煩雑になりセキュリティの向上に繋がらないことに注意.

サービスの運用者は, アクセス権限管理を適宜見直さなければならない. 特に, 開発者/運用者の異動がある場合, 適切に権限の付与/剥奪を行なわなければならない.

4.7.6.2. ログの取得

サービスの開発者は, 情報へのアクセスログの取得機能を実装しなればならない.

ログの内容には少なくとも以下を含めなければならない. なお, ログに機密情報そのものを含めてはならない.

  • アクセス者 (例: 開発者/運用者のid, 一般利用者)
  • アクセス経路 (例: フロント側からか管理ツールからか)
  • アクセスの概要
    • 閲覧/登録/変更/削除
    • 処理件数/範囲

サービスの開発者/運用者であってもログに対して不正を行なえないことが望ましいが, コストをかけずに行なうことは難しいので可能な範囲でよい.

4.7.6.3. アクセスログの監視

サービスの運用者は, 取得したアクセスログを定期的に監視し異常がないか確認したほうがよい. ただし, アクセス者が社内の者と一般利用者に限られる場合は, 定期的な監視をしなくてもよい.

4.7.6.4. アクセスログの保持期間

サービスは, アクセスログの保持期間を定めなければならない. 1年を推奨する.

4.7.7. ユーザIDによる名寄せの防止

ユーザIDによるユーザ情報の名寄せを防ぐため, 社外サービスとユーザIDを共用する場合には以下に示す対策を行なう必要がある.

4.7.7.1. サービスのユーザIDの外部提供

サービスのユーザを一意に判定するIDを外部のサービスに提供する場合, サービスのユーザIDをそのものを外部のサービスに提供してはならない. サービスのユーザIDと対応する別のIDを外部サービスごとに作成しなければならない.

作成方法は別のIDに重複が発生せずサービスのIDの推測が困難であれば自由である.

4.7.7.2. 外部のユーザIDの利用

サービスで外部のユーザIDに相当するものを利用する場合, その外部ユーザIDがサービス専用に発行されていることが明らかでない場合, 可能な限りそのままDBには保存せず暗号化ないしハッシュ化を行なう必要がある. 要件上不可能と判断される場合はセキュリティ委員会に報告しなければならない.