💾 資格バッジ図鑑
2回正解で卒業=獲得。
今日の学習スタンプ
今日、情報セキュリティの勉強をした——1問だけでもOK、続けることが合格への近道。
ルールは「知ってる」より「守れた」が偉い。30個で台紙コンプリート!
📖 まず学ぶ(講義)
前知識ゼロからでも読めるように書いています。
📚 講義の全文(42本)
情報セキュリティマネジメント対策 の講義42本を、そのまま読める形で置いています。アプリを起動しなくても、ここだけで内容を確かめられます。各見出しを開くと、本文・用語・図表・例題・出典が出ます。
情報セキュリティ全般
情報セキュリティとは何を守ることか
情報セキュリティが守る「機密性・完全性・可用性」と、それを脅かす脅威・脆弱性・リスクの関係を、業務判断の目線で整理します。
情報セキュリティとは、情報の機密性(Confidentiality)・完全性(Integrity)・可用性(Availability)を維持することです。この三つは頭文字をとってCIAと呼ばれ、JIS Q 27000でも情報セキュリティの定義の中心に置かれています。機密性は「許可された人だけが見られる」こと、完全性は「内容が正確で書き換えられていない」こと、可用性は「必要なときに使える」ことです。
現場でまず身につけたいのは、起きた出来事がCIAのどれを損なったかを言い当てる力です。顧客名簿が外部に流出したなら機密性、Webサイトのトップページが書き換えられたなら完全性、DDoS攻撃でオンラインサービスが止まったなら可用性が損なわれています。ランサムウェアのようにファイルを暗号化して業務を止める攻撃は可用性を、暗号化と同時にデータを盗んで公開すると脅す二重脅迫はさらに機密性も損ないます。
CIAに加えて、真正性・責任追跡性・否認防止・信頼性の四つを合わせて情報セキュリティの七要素と呼ぶことがあります。真正性は「名乗っているとおりの本人・本物であること」、責任追跡性は「誰が何をしたかを後から追えること」、否認防止は「やっていないと言い逃れできないこと」、信頼性は「意図したとおりに動き、期待した結果が得られること」です。IDとパスワードによる本人確認は真正性、操作ログの取得は責任追跡性、デジタル署名は否認防止の代表例です。
守る対象は情報資産です。情報資産には顧客名簿や設計図のような電子データだけでなく、紙の書類、それらを扱うサーバやパソコン、業務ソフトウェア、さらには従業員が持つノウハウも含まれます。情報資産は台帳にまとめたうえで、機密度と重要度に応じて「極秘・社外秘・公開」などに分類し、分類ごとに取扱いルール(保管・持出し・複製・廃棄の可否)を決めます。分類がなければ、どの情報にどこまでコストをかけて守るかを判断できません。
脅威・脆弱性・リスクは混同しやすい三語です。脅威は情報資産に損害を与える可能性のある原因(不正アクセス、マルウェア、火災、内部不正など)、脆弱性は脅威につけ込まれる弱点(パッチ未適用、施錠されない書庫、教育不足など)、リスクは脅威が脆弱性を突いて実際に損害が発生する可能性です。リスクの大きさは「脅威の大きさ×脆弱性の大きさ×情報資産の価値」でとらえられます。この式が示す重要な点は、脅威そのものは自社で減らせなくても、脆弱性をつぶせばリスクは下がるということです。
情報セキュリティが損なわれると、被害は情報そのものにとどまりません。事業面では業務停止や復旧費用、信用面では顧客離れやブランド価値の低下、法的責任の面では個人情報保護法に基づく個人情報保護委員会への報告・本人への通知義務、損害賠償請求、契約違反による取引停止などが生じます。情報セキュリティリーダーは、技術の細部よりも「何が失われるとどれだけ困るか」を経営の言葉で説明できることが求められます。
| 区分 | 特性 | 意味 | 損なわれた例 | 主な対策 |
|---|---|---|---|---|
| CIA | 機密性 | 許可された人だけが見られる | 顧客名簿が外部に流出した | アクセス権設定・暗号化・施錠 |
| CIA | 完全性 | 内容が正確で書き換えられていない | Webサイトが改ざんされた | 改ざん検知・ハッシュ・変更管理 |
| CIA | 可用性 | 必要なときに使える | DDoS攻撃でサービスが停止した | 冗長化・バックアップ・BCP |
| 追加 | 真正性 | 名乗りどおりの本人・本物である | 他人になりすまして発注された | 本人認証・多要素認証 |
| 追加 | 責任追跡性 | 誰が何をしたか追跡できる | IDを共用し操作者を特定できない | ID個別付与・操作ログ取得 |
| 追加 | 否認防止 | やっていないと言い逃れできない | 注文した覚えはないと主張された | デジタル署名・タイムスタンプ |
| 追加 | 信頼性 | 意図どおりに動き期待した結果が出る | 不具合で集計値が毎回変わる | テスト・変更管理・品質管理 |
- 機密性
- 許可された者だけが情報にアクセスできる状態を保つ特性。アクセス権の設定、暗号化、施錠保管などで確保する。顧客名簿の流出や盗み見は機密性が損なわれた例。
- 完全性
- 情報が正確かつ完全で、許可されない書換えや破壊がされていない特性。Webサイトの改ざん、データの不正な書換え、送信中のデータ改変は完全性が損なわれた例。
- 可用性
- 許可された者が必要なときに情報や情報システムを使える特性。DDoS攻撃による停止、ランサムウェアによる暗号化、機器故障や停電での業務停止は可用性が損なわれた例。
- 真正性
- 利用者や情報が主張どおりの本人・本物であることを確実にする特性。なりすましを防ぐための本人認証や、送信元が正しいことの確認がこれにあたる。
- 責任追跡性
- ある行為が誰によって行われたかを一意に追跡できる特性。利用者IDの個人単位の割当てと操作ログの取得・保管によって確保する。IDの共用は責任追跡性を失わせる。
- 否認防止
- ある行為や事象が起きたことを後から否定できないようにする特性。デジタル署名やタイムスタンプ、改ざんできないログの保全によって実現する。
- 信頼性
- システムや処理が意図したとおりに動作し、期待した結果が一貫して得られる特性。プログラムの不具合による誤集計は信頼性が損なわれた状態といえる。
- 情報資産
- 組織にとって価値があり守るべき対象。電子データ、紙の書類、ハードウェア、ソフトウェア、通信設備、さらに人が持つ知識やノウハウも含む。台帳で管理する。
- 脅威
- 情報資産に損害を与える可能性のある事象や原因。不正アクセス、マルウェア、内部不正、盗難、地震や火災、機器故障などが該当する。多くは組織の外にあり自社では消せない。
- 脆弱性
- 脅威につけ込まれる弱点。ソフトウェアの欠陥、設定の不備、運用手順の不備、教育不足による人の油断など。組織の努力で減らせるのは主にこちら。
- リスク
- 脅威が脆弱性を突くことで情報資産に損害が生じる可能性。大きさは脅威×脆弱性×資産価値でとらえる。どれか一つがゼロならリスクは顕在化しない。
例題 社内の共有サーバに保存していた見積書ファイルが、退職者のIDで持ち出され競合他社に渡った。損なわれたのはCIAのどれか。
機密性。許可されていない相手に情報が渡ったため。なお退職者IDが残っていたことは脆弱性、持ち出す行為は脅威にあたる。ファイル自体は書き換わっておらず利用もできるので完全性・可用性は損なわれていない。
例題 自社の受注システムに大量のアクセスが集中し、丸一日受注できなかった。損なわれたのはCIAのどれか。
可用性。情報は漏れておらず内容も正しいままだが、必要なときに使えない状態になった。停止による機会損失も可用性の被害として評価する。
例題 リスク=脅威×脆弱性×資産価値と考えたとき、自社で最も直接的に下げられるのはどれか。
脆弱性。地震やマルウェアの流行といった脅威は自社では消せず、資産価値も業務上下げられないことが多い。パッチ適用・設定見直し・教育で脆弱性を下げることがリスク低減の中心になる。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類1 情報セキュリティ/JIS Q 27000(情報セキュリティマネジメントシステム-用語)
脅威を知る(人・環境・技術)
脅威を人的・物理的・技術的に分けて整理し、内部不正の起き方(不正のトライアングル)とソーシャルエンジニアリングの手口を押さえます。
脅威は大きく人的脅威・物理的脅威・技術的脅威の三つに分けて考えると整理しやすくなります。人的脅威は人の行動によるもので、誤操作・紛失・置き忘れなどの過失と、内部不正・情報の持出しなどの故意の両方を含みます。物理的脅威は地震・火災・水害・落雷・停電といった災害や、機器の盗難・破壊など、モノや環境に関わるものです。技術的脅威は不正アクセス、マルウェア感染、盗聴、なりすまし、サービス妨害など、情報技術を用いて行われるものです。
統計的にも実務感覚でも、情報漏えいの多くは外部からの高度な攻撃ではなく、メールの誤送信、書類やUSBメモリの紛失、宛先の取り違えといった人的な過失から起きます。情報セキュリティリーダーが最初に手をつけるべきは、派手な攻撃対策よりも、日常業務のうっかりを減らす手順とチェックの仕組みであることが多いのです。
故意の脅威として深刻なのが内部不正です。内部者は正規のアクセス権を持ち、社内の事情も分かっているため、外部からの攻撃より発見が遅れがちです。内部不正が起きる条件を説明するモデルが不正のトライアングルで、機会・動機・正当化の三つがそろったときに不正が起きるとされます。機会は「やろうと思えばできてしまう環境」(アクセス権が広すぎる、チェックがない、ログを誰も見ない)、動機は「やりたくなる事情」(借金、人事評価への不満、ノルマ、退職後の転職先での利用)、正当化は「これくらい構わないという言い訳」(自分が作った資料だから、みんなやっている、会社が悪い)です。
この三つのうち、組織が最も確実に減らせるのは機会です。アクセス権を業務に必要な最小限にする、重要な操作は複数人で行う、定期的な人事異動や休暇取得でひとりに業務を抱えさせない、ログを取得して定期的に確認していると周知する、といった管理策が有効です。動機は相談窓口や公正な評価、正当化は教育と誓約書の取り交わしで働きかけます。
ソーシャルエンジニアリングは、技術ではなく人の心理や行動の隙を突いて情報を得る手口です。上司や情報システム部門を名乗って電話でパスワードを聞き出すなりすまし、画面や入力を背後からのぞき見るショルダーハッキング、ごみ箱や廃棄書類をあさって情報を集めるトラッシング(スカベンジング)、社員の後ろについて入退室ゲートを通り抜けるピギーバック(共連れ)などがあります。いずれも高度な技術は不要で、システム側の対策では防ぎきれないため、手順の徹底と教育が対策の中心になります。
組織固有のリスクとして、シャドーIT、退職者リスク、サプライチェーンリスクも押さえておきます。シャドーITは、会社が把握・許可していない機器やクラウドサービスを従業員が業務に使ってしまう状態で、管理も監視も及ばないため漏えいの温床になります。退職者リスクは、退職者のアカウントが残っていたり、在職中に持ち出した情報が転職先で使われたりするもので、退職時のアカウント即時停止・貸与品回収・秘密保持の確認が対策です。サプライチェーンリスクは、委託先や取引先、あるいは自社が使うソフトウェアの提供元が侵害され、そこを経由して自社が被害を受けるものです。自社だけ守っても足りず、委託先の管理と契約での取決めが必要になります。
| 区分 | 脅威 | 具体例 | 主な対策 |
|---|---|---|---|
| 人的(過失) | 誤操作・紛失 | メールの誤送信、書類やUSBの置き忘れ | 宛先ダブルチェック、持出し制限、暗号化 |
| 人的(故意) | 内部不正 | 退職前に顧客名簿を持ち出す | 最小権限、ログ確認、職務分離、誓約書 |
| 人的(故意) | ソーシャルエンジニアリング | 情報システム部門を名乗る電話でパスワードを聞く | 本人確認手順の徹底、電話での回答禁止、教育 |
| 人的(管理外) | シャドーIT | 私物クラウドに業務ファイルを保存 | 利用申請制度、許可サービスの提示、通信の可視化 |
| 人的(退職) | 退職者リスク | 退職者のIDが有効なまま残る | 退職時の即時アカウント停止、貸与品回収 |
| 物理的 | 災害・事故 | 地震・火災・水害・停電での設備停止 | 耐震、遠隔地バックアップ、UPS、BCP |
| 物理的 | 盗難・破壊 | ノートPCや書類の盗難、機器の破壊 | 入退室管理、施錠保管、セキュリティワイヤ |
| 技術的 | 不正アクセス・マルウェア | 外部からの侵入、ランサムウェア感染 | パッチ適用、認証強化、マルウェア対策ソフト |
| 技術的・委託 | サプライチェーン | 委託先経由での情報漏えい | 委託先選定基準、契約での取決め、監査 |
- 人的脅威
- 人の行動に起因する脅威。誤操作・紛失・誤送信などの過失と、内部不正・情報の持出しなどの故意を含む。ソーシャルエンジニアリングもここに分類される。
- 物理的脅威
- 地震・火災・水害・落雷・停電などの災害や事故、機器の盗難・破壊など、物理的な環境やモノに関わる脅威。冗長化や耐震・入退室管理で備える。
- 技術的脅威
- 不正アクセス、マルウェア感染、盗聴、なりすまし、サービス妨害など、情報技術を手段として行われる脅威。技術的対策と運用の両輪で対応する。
- 内部不正
- 従業員・元従業員・委託先要員など正規のアクセス権を持つ者による意図的な不正行為。正規の権限を使うため検知が難しく、被害が大きくなりやすい。
- 不正のトライアングル
- 不正は機会・動機・正当化の三要素がそろったときに起きるとする考え方。組織が管理策で最も直接的に減らせるのは機会である。
- ソーシャルエンジニアリング
- 技術ではなく人の心理や行動の隙を突いて情報を入手する手口の総称。なりすまし電話、のぞき見、トラッシング、共連れなどが含まれる。
- ショルダーハッキング
- 背後や周囲からディスプレイやキー入力をのぞき見て、パスワードや機密情報を盗み取る手口。のぞき見防止フィルタや画面の向き、離席時のロックで対策する。
- トラッシング
- ごみ箱や廃棄物をあさって、書類・メモ・記憶媒体から情報を収集する手口。スカベンジングとも呼ぶ。シュレッダー処理や機密文書の施錠回収で対策する。
- シャドーIT
- 組織が把握・承認していない機器やクラウドサービスを従業員が業務に使っている状態。管理や監視が及ばず、脆弱性の放置や情報漏えいの原因になる。
- サプライチェーンリスク
- 委託先・取引先やソフトウェア提供元が侵害され、それを経由して自組織が被害を受けるリスク。委託先の選定基準、契約での取決め、定期的な監査で管理する。
- 共連れ
- 入退室管理された扉を、正規に入室する人の直後について通り抜ける行為。ピギーバックとも呼ぶ。アンチパスバックやマントラップ、社員の声かけで防ぐ。
例題 経理担当者が一人で長年、支払処理を承認から実行まで担当している。不正のトライアングルのどの要素が大きい状態か。
機会。一人で完結できチェックが働かないため、やろうと思えばできてしまう。職務分離、複数人承認、定期的な担当交代や連続休暇の取得が対策になる。動機や正当化は本人の内心の問題で、組織が直接消すことは難しい。
例題 「システム部の者ですが、障害調査のため今すぐパスワードを教えてください」という電話があった。分類と対応は。
人的脅威のソーシャルエンジニアリング(なりすまし)。パスワードは誰にも伝えないのが原則で、いったん電話を切り、社内名簿の番号にかけ直して確認する。急がせる言い回しは典型的な手口なので、その場で判断しないことが重要。
例題 会社が禁止していない代わりに把握もしていない無料ファイル転送サービスを、大容量データの受渡しに使っている。何が問題か。
シャドーITにあたる。保存先・保管期間・アクセス範囲を組織が管理できず、事故が起きても把握や対応ができない。利用可能なサービスを組織として決めて提示し、申請と記録の仕組みを整えることが対策になる。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類1 情報セキュリティ(脅威)/IPA「組織における内部不正防止ガイドライン」
脆弱性を知る
脆弱性の種類とパッチ管理の考え方、CVE・CVSS・JVNといった共通の物差し、診断手法の違いを管理者の目線で押さえます。
脆弱性とは、脅威につけ込まれる弱点のことです。ソフトウェアの欠陥だけを指すと思われがちですが、実際には四つの層があります。ソフトウェアの欠陥(プログラムの不具合やセキュリティホール)、設定の不備(初期パスワードのまま、必要のない公開設定、過剰なアクセス権)、運用の不備(棚卸しがされていない、ログを誰も見ていない、退職者のIDが残る)、そして人の油断(不審メールを開く、パスワードを使い回す、机上に書類を放置する)です。管理の対象としては後ろの二つ、すなわち運用と人のほうが範囲も影響も大きいことが少なくありません。
ソフトウェアの脆弱性への基本対策はパッチ(修正プログラム)の適用です。ここで管理者が問われるのは「すぐ当てるか、検証してから当てるか」の判断です。業務システムでは、パッチが既存の業務アプリと干渉して止まるおそれがあるため、検証環境での確認と適用計画が要ります。一方で危険度が高く悪用が始まっている脆弱性は、検証を待つ間の被害のほうが大きいこともあります。そこで、資産台帳でどの機器にどのソフトが入っているかを把握し、危険度と業務影響を見比べて優先順位をつける仕組みが必要になります。これが脆弱性管理です。
ゼロデイ脆弱性は、修正プログラムが提供される前の段階の脆弱性、またはその状態で行われる攻撃を指します。パッチが存在しないため、パッチ適用では防げません。この場合は、ベンダが公表する回避策(該当機能の停止、設定変更)の適用、通信の遮断や隔離、監視の強化、被害を前提としたバックアップからの復旧準備といった多層的な備えで被害を抑えます。「パッチが出るまで何もできない」ではなく「出るまでの間をどうしのぐか」を考えるのが管理者の役割です。
脆弱性を組織の外と共通の言葉で扱うために、番号や指標が整備されています。CVEは個々の脆弱性に世界共通で付けられる識別番号で、同じ脆弱性を関係者が取り違えずに指せるようにするものです。CVSSは脆弱性の深刻度を0.0〜10.0の数値と評価基準で表す共通の物差しで、基本評価基準・現状評価基準・環境評価基準からなります。CVSSの値は「危険度の目安」であって、自社での優先順位そのものではありません。値が高くても該当機器がインターネットから隔離されていれば急がないこともあり、環境評価基準はそうした自組織の事情を反映するためのものです。JVNは日本国内向けの脆弱性対策情報ポータルで、JPCERT/CCとIPAが共同運営し、日本語で対策情報を確認できます。
脆弱性を見つける手段には、脆弱性診断(脆弱性検査)とペネトレーションテストがあります。脆弱性診断は、既知の脆弱性がないかを網羅的に洗い出す健康診断のような活動で、ツールによるスキャンが中心です。ペネトレーションテストは、実際の攻撃者と同じように侵入を試み、目的(重要データへの到達など)を達成できるかを検証する活動で、網羅性より「本当に突破されるか」を見ます。目的が違うので、どちらか一方で十分ということはありません。いずれも実施には対象システムの管理者の許可が必要で、無断で行えば不正アクセス禁止法などに触れるおそれがあります。
そもそも脆弱性を作り込まないという考え方がセキュリティバイデザインです。システムの企画・設計の段階からセキュリティを組み込む考え方で、完成後に対策を後付けするより費用も手戻りも小さくなります。プライバシーについて同様の考え方をプライバシーバイデザインといいます。また、サポートが終了した(EOL:End of Life)OSやソフトウェアは、新たな脆弱性が見つかっても修正されません。動いているから使い続けるのではなく、サポート期限を資産台帳で管理し、期限前に更新計画を立てることが必要です。前回学んだシャドーITは、この管理の網から外れる点でも危険です。
| 区分 | 脆弱性の例 | 主な対策 | 気づく手段 |
|---|---|---|---|
| ソフトウェアの欠陥 | OSやアプリのセキュリティホール | パッチ適用、回避策の適用 | JVN・ベンダ情報、脆弱性診断 |
| ソフトウェアの欠陥 | ゼロデイ(修正未提供) | 機能停止・隔離・監視強化・復旧準備 | ベンダ告知、注意喚起、監視ログ |
| 設定の不備 | 初期パスワードのまま、過剰な公開設定 | 設定基準の整備と設定値の点検 | 設定監査、構成管理との突合 |
| 設定の不備 | アクセス権が広すぎる | 最小権限、定期的な権限棚卸し | 権限一覧のレビュー |
| 運用の不備 | 退職者のIDが残る、ログ未確認 | 退職時手続の徹底、ログ点検の定例化 | 内部監査、ID棚卸し |
| 運用の不備 | EOL製品を使い続けている | サポート期限管理と更新計画 | 資産台帳の期限チェック |
| 人の油断 | 不審メールを開く、パスワード使い回し | 教育・訓練、多要素認証 | 標的型メール訓練の結果 |
| 管理外 | シャドーIT | 利用申請制度、許可サービスの明示 | 通信の可視化、利用実態調査 |
- 脆弱性
- 脅威につけ込まれる弱点。ソフトウェアの欠陥だけでなく、設定の不備、運用手順の不備、教育不足による人の油断も含む広い概念である。
- セキュリティホール
- ソフトウェアの設計や実装の不具合のうち、悪用されると不正アクセスや権限昇格などにつながるもの。修正プログラム(パッチ)の適用が基本対策となる。
- パッチ管理
- 資産台帳で対象を把握し、脆弱性情報の収集・危険度と業務影響の評価・検証・適用・記録までを継続的に回す運用。適用の可否と時期を決めるのが管理者の判断となる。
- ゼロデイ脆弱性
- 修正プログラムが提供される前の脆弱性、またはその状態を突く攻撃。パッチ適用では防げないため、回避策の適用、隔離、監視強化、復旧準備で被害を抑える。
- CVE
- 個別の脆弱性に付与される世界共通の識別番号。関係者が同じ脆弱性を取り違えずに参照できるようにするための仕組みで、深刻度そのものは表さない。
- CVSS
- 脆弱性の深刻度を共通の基準で評価する手法。基本評価基準・現状評価基準・環境評価基準からなり、0.0〜10.0の数値で表す。自組織の優先順位は環境も踏まえて決める。
- JVN
- JPCERT/CCとIPAが共同運営する、日本国内向けの脆弱性対策情報ポータルサイト。国内で使われる製品の脆弱性と対策情報を日本語で確認できる。
- 脆弱性診断
- 既知の脆弱性が存在しないかを網羅的に洗い出す検査。ツールによるスキャンが中心で、健康診断に相当する。実施には対象システムの管理者の許可が必要。
- ペネトレーションテスト
- 攻撃者の視点で実際に侵入を試み、目的を達成できるかを検証するテスト。網羅性より突破可否の確認に主眼がある。許可と範囲の合意を得て実施する。
- セキュリティバイデザイン
- システムの企画・設計段階からセキュリティを組み込む考え方。完成後の後付け対策より費用・手戻りが小さく、根本的な脆弱性の作り込みを防げる。
- EOL(サポート終了)
- 製品のサポートが終了し、新たな脆弱性が見つかっても修正が提供されなくなる状態。動作していても放置は危険で、期限を管理し事前に更新計画を立てる。
例題 利用中の業務ソフトに深刻な脆弱性が公表されたが、修正プログラムはまだ提供されていない。まず検討すべきことは。
ゼロデイの状態なのでパッチ適用は選べない。ベンダが示す回避策(該当機能の停止や設定変更)の適用、対象機器のネットワーク隔離や外部公開の停止、監視の強化、バックアップからの復旧準備を組み合わせて、パッチ提供までの期間をしのぐ。
例題 CVSSの基本値が9.8の脆弱性がある。ただちに最優先で対応すべきと言い切れるか。
言い切れない。CVSSは共通の物差しであって自社の優先順位そのものではない。該当機器がインターネットから隔離されている、代替の防御があるなどの事情は環境評価基準で反映する。資産の重要度と露出度を合わせて優先順位を決める。
例題 脆弱性診断とペネトレーションテストの違いを一言で説明すると。
脆弱性診断は既知の弱点を網羅的に洗い出す健康診断、ペネトレーションテストは攻撃者と同じ手順で実際に侵入できるかを試す実地検証。目的が異なるため互いの代替にはならず、いずれも管理者の許可を得て実施する。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類1 情報セキュリティ(脆弱性)/JVN(JPCERT/CC・IPA共同運営)/CVSS(FIRSTが策定)
マルウェアを知る
ウイルス・ワーム・トロイの木馬の違いから、ランサムウェアやボットネットまで、種類ごとの特徴と感染経路・検知方法を整理します。
マルウェアは、悪意をもって作られたソフトウェアの総称です。まず押さえるべきは、古典的な三分類の違いです。ウイルス(狭義)は単独では存在できず、他のプログラムやファイルに寄生して、そのファイルが実行されることで増殖します。ワームは寄生先を必要とせず、それ自体が独立したプログラムとしてネットワークを通じて自己増殖して広がります。トロイの木馬は、便利なツールや正規のファイルを装って利用者に自ら実行させるもので、自己増殖はしないのが特徴です。「自己増殖するか」「寄生先が要るか」の二点で見分けると混乱しません。
ランサムウェアは、ファイルやシステムを暗号化して使えなくし、復号と引き換えに身代金(ransom)を要求するマルウェアです。近年は暗号化する前にデータを窃取し、支払わなければ公開すると脅す二重脅迫(ダブルエクストーション)が主流になっています。単純な暗号化なら失われるのは可用性ですが、二重脅迫では機密性も同時に損なわれます。だからこそ「バックアップがあるから支払わなくてよい」で終わらせず、漏えいを前提とした報告・通知の準備も必要です。身代金を支払っても確実に復号できる保証はなく、犯罪組織への資金提供にもなるため、支払わずに済む備え(オフラインまたは分離したバックアップと復旧手順の訓練)が基本方針になります。
情報を盗むタイプも複数あります。スパイウェアは利用者に気づかれずに情報を収集して外部へ送信するもの、キーロガーはキーボード入力を記録してIDやパスワード、クレジットカード番号を盗むものです。バックドアは正規の認証を通らずに侵入できる裏口を仕掛けるもので、いったん設置されると駆除後も再侵入を許します。RAT(遠隔操作型のマルウェア)は、攻撃者が感染端末を遠隔から自由に操作できるようにするもので、標的型攻撃で長期間の潜伏に使われます。
ボットは、感染した機器を攻撃者の指示どおりに動かすマルウェアです。多数のボット感染機器が束ねられたネットワークをボットネットと呼び、攻撃者はC&Cサーバ(指令サーバ)から一斉に指示を出して、DDoS攻撃や迷惑メールの大量送信などを行わせます。重要なのは、感染した組織は被害者であると同時に、他者への攻撃の踏み台という加害者にもなる点です。社内から見慣れない外部宛ての通信が続いている、という兆候はC&C通信の可能性があり、速やかな切離しと調査が必要になります。
実行形式のファイルだけが危険とは限りません。マクロウイルスは文書や表計算ファイルのマクロ機能を悪用するもので、添付ファイルを開いてマクロを有効化した瞬間に動き出します。ファイルレスマルウェアは、ディスク上にファイルを置かずメモリ上や正規のOS機能(スクリプト実行機能など)を悪用して動作するため、ファイルを調べるパターンマッチングでは見つけにくい厄介な種類です。ダウンローダは、それ自体は小さく無害に見えますが、侵入後に本体となるマルウェアを外部から呼び込む役割を担います。
感染経路は、メールの添付ファイルやリンク、改ざんされたWebサイトの閲覧、USBメモリなどの外部媒体、ソフトウェアの脆弱性を突いたネットワーク経由の侵入、正規ソフトの配布元やアップデート機構が侵害されるサプライチェーン経由などがあります。検知方法にはそれぞれ得意不得意があります。パターンマッチング(シグネチャ法)は既知のマルウェアの特徴を記録した定義ファイルと照合する方式で、確実だが未知のものには無力です。ビヘイビア法(振る舞い検知)は実行時の挙動を監視して不審な動作で判断し、ヒューリスティック法は構造や命令の特徴から推定します。サンドボックスは隔離した仮想環境で実際に動かして安全性を確かめる方式です。未知のマルウェアに備えるには、定義ファイルの更新に加えてこれらを組み合わせ、さらに感染を前提とした検知・隔離・復旧の体制を用意しておくことが求められます。
| 区分 | 種類 | 自己増殖 | 特徴 | 主に損なわれる特性 |
|---|---|---|---|---|
| 古典3分類 | ウイルス(狭義) | する(寄生) | 他のファイルに寄生し実行で増殖 | 完全性・可用性 |
| 古典3分類 | ワーム | する(単独) | 寄生先を必要とせずネットワーク経由で自己増殖 | 可用性 |
| 古典3分類 | トロイの木馬 | しない | 有用なソフトを装い利用者に実行させる | 機密性・完全性 |
| 金銭目的 | ランサムウェア | 種類による | 暗号化し身代金要求、二重脅迫で公開も脅す | 可用性(+機密性) |
| 情報窃取 | スパイウェア | しない | 気づかれずに情報を収集し外部送信 | 機密性 |
| 情報窃取 | キーロガー | しない | キー入力を記録しID・パスワードを盗む | 機密性 |
| 遠隔操作 | ボット | 種類による | C&Cサーバの指令で動き踏み台にされる | 可用性・機密性 |
| 遠隔操作 | RAT | しない | 攻撃者が端末を遠隔操作、長期潜伏 | 機密性・完全性 |
| 侵入補助 | バックドア | しない | 認証を経ずに侵入できる裏口を作る | 機密性・完全性 |
| 侵入補助 | ダウンローダ | しない | 侵入後に本体を外部から取得して実行 | (後続の被害による) |
| 検知回避 | ファイルレス | しない | メモリや正規機能を悪用しファイルを残さない | 機密性・完全性 |
| 文書悪用 | マクロウイルス | する | 文書のマクロ機能を悪用して動作 | 完全性・可用性 |
- マルウェア
- 悪意をもって作られたソフトウェアの総称。ウイルス、ワーム、トロイの木馬、ランサムウェア、スパイウェア、ボットなどを包括して指す語である。
- ウイルス(狭義)
- 単独では存在できず、他のプログラムやファイルに寄生し、そのファイルが実行されることで増殖するマルウェア。寄生先を必要とする点がワームとの違い。
- ワーム
- 寄生先を必要とせず、独立したプログラムとしてネットワークを通じて自己増殖し感染を広げるマルウェア。増殖速度が速く、帯域を圧迫することもある。
- トロイの木馬
- 有用なソフトウェアや正規ファイルを装って利用者に実行させ、裏で不正な処理を行うマルウェア。自己増殖しない点がウイルスやワームとの決定的な違い。
- ランサムウェア
- ファイルやシステムを暗号化して使用不能にし、復旧と引換えに身代金を要求するマルウェア。窃取したデータの公開もあわせて脅す二重脅迫が主流となっている。
- スパイウェア
- 利用者に気づかれないように端末内の情報や操作内容を収集し、外部へ送信するマルウェア。破壊や暗号化は行わず、潜伏して情報を盗み続ける点が特徴。
- ボット/ボットネット
- 感染機器を攻撃者の指示どおりに動かすマルウェアがボット。多数のボット感染機器を束ねた攻撃基盤がボットネットで、DDoS攻撃や迷惑メール送信に悪用される。
- C&Cサーバ
- ボットに指令を送り、盗んだ情報を受け取る指令サーバ。感染端末から外部C&Cサーバへの不審な通信は感染の重要な兆候であり、遮断と調査の対象となる。
- キーロガー
- キーボードの入力内容を記録して盗み取る手段。ソフトウェア型のほか、端末とキーボードの間に挟む機器型もある。IDやパスワードの窃取に使われる。
- バックドア
- 正規の認証手続を経ずに侵入できるようにした裏口。設置されると、表面上の駆除後も再侵入を許すため、侵入経路の遮断と全体的な点検が必要になる。
- RAT
- 感染端末を攻撃者が遠隔から操作できるようにするマルウェア。標的型攻撃で長期間潜伏し、内部の探索や情報の持出しの足がかりとして使われる。
- ファイルレスマルウェア
- ディスク上にファイルを残さず、メモリ上や正規のOS機能・スクリプト実行機能を悪用して動作するマルウェア。ファイル走査型の検知では発見が難しい。
- マクロウイルス
- 文書ファイルや表計算ファイルのマクロ機能を悪用するマルウェア。添付ファイルを開きマクロを有効化することで動作するため、マクロの既定無効化が有効な対策。
- ダウンローダ
- それ自体は小さく無害に見えるが、侵入後に外部から本体となるマルウェアを取得して実行させる役割を担うプログラム。初期侵入の足がかりに使われる。
- パターンマッチング法
- 既知のマルウェアの特徴を記録した定義ファイルと照合して検知する方式。シグネチャ法とも呼ぶ。確実だが未知のマルウェアや亜種には対応できない。
- ビヘイビア法
- プログラムの実行時の挙動を監視し、不審な動作を検知する方式。振る舞い検知とも呼ぶ。定義ファイルにない未知のマルウェアにも対応しうる。
- サンドボックス
- 隔離した仮想環境で対象を実際に動作させ、挙動から安全性を判断する仕組み。未知のマルウェアの解析に有効だが、検知を回避する種類も存在する。
例題 無料の便利ツールとして配布されていたソフトを社員がインストールしたところ、裏で社内情報が外部に送信されていた。自己増殖の形跡はない。何にあたるか。
トロイの木馬。有用なソフトを装って利用者自身に実行させ、自己増殖しないのが特徴。ワームなら寄生先なしに自己増殖し、ウイルスなら他のファイルに寄生して増殖するため、いずれも当てはまらない。
例題 ランサムウェアの被害に備え「バックアップを取っているので身代金は払わない」方針としたが、これで十分か。
不十分。二重脅迫ではデータを窃取したうえで公開すると脅すため、復旧できても機密性の被害は残る。バックアップは本番から分離・オフライン保管し復旧訓練を行うとともに、漏えい時の報告・通知の手順も準備しておく必要がある。
例題 定義ファイルを最新にしているのに未知のマルウェアで被害が出た。どう考えるべきか。
パターンマッチング法は既知のものにしか対応できないため、定義ファイルの更新だけでは未知や亜種を防げない。ビヘイビア法やサンドボックスなど異なる原理の検知を組み合わせ、加えて感染を前提とした検知・隔離・復旧の体制を整えておく。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類1 情報セキュリティ(マルウェア)/IPA「情報セキュリティ10大脅威」
サイバー攻撃手法
人をだます攻撃
標的型攻撃・フィッシング・BECなど「人」を狙う攻撃の見分け方と、組織としての備え方が分かります。
サイバー攻撃には、システムの穴を突くものと、人の心理や業務の慣れを突くものがあります。後者の代表が標的型攻撃メールやフィッシングです。どれほど高価な機器を入れても、受け取った人が添付ファイルを開いてしまえば侵入は成立します。だからこそ情報セキュリティリーダーは、攻撃の細かい仕組みよりも「何が起きるか」「気づいたら誰に何を報告するか」を職場に浸透させる役目を負います。
標的型攻撃は、特定の組織や個人を狙って情報を盗み出す攻撃です。取引先や社内の別部署を装ったメールに、業務に関係ありそうな件名と添付ファイルを付けて送ってきます。無差別のばらまき型と違い、実在の担当者名や進行中の案件名が書かれているため、文面だけで見抜くのは困難です。何度か普通のやり取りを重ねて警戒を解いてから攻撃用の添付を送る手口を「やり取り型」と呼びます。また、標的が日常的に見ている業界団体などのWebサイトをあらかじめ改ざんしておき、閲覧しただけでマルウェアに感染させる手口を「水飲み場型攻撃」といいます。獲物が水を飲みに来る場所で待ち伏せするイメージです。
フィッシングは、金融機関や宅配業者、社内システムなどを装ったメールで偽サイトへ誘導し、IDやパスワード、クレジットカード番号を入力させて盗む攻撃です。SMS(ショートメッセージ)を使う場合を「スミッシング」、音声通話を使う場合を「ビッシング」と呼びます。SMSは差出人表示を偽装しやすく、本物の通知と同じスレッドに紛れ込むことがあるため、携帯電話に届いた短いメッセージほど注意が要ります。
ビジネスメール詐欺(BEC)は、経営者や取引先になりすまして経理担当者にメールを送り、偽の口座へ送金させる攻撃です。マルウェアを使わないため、ウイルス対策ソフトでは検知できません。「社長案件なので他言無用」「今日中に振り込んでほしい」と急がせ、確認させないのが常套手段です。有効な対策は技術ではなく業務手順の側にあります。すなわち、振込先の変更は必ずメール以外の手段(登録済みの電話番号への架電など)で確認する、一定金額以上は複数人の承認を必須にする、といったルールです。
なりすましメールは、送信者アドレスの表示を本物そっくりに偽装したものです。SPF・DKIM・DMARCといった送信ドメイン認証を導入すると、詐称メールを受信側で検知・遮断しやすくなります。偽の警告(サポート詐欺)は、Webの閲覧中に「ウイルスに感染しました」という警告画面と警告音を出し、表示された電話番号に電話させて遠隔操作ソフトを入れさせたり、サポート料金をだまし取ったりする手口です。この画面は単なるWebページなので、慌てず画面を閉じるかブラウザを終了させ、表示された番号には絶対に電話しないことが正解です。
SNSも攻撃の入口になります。攻撃者は公開されたプロフィールや投稿から所属・役職・取引先・出張予定を集め、標的型攻撃メールの精度を上げます。転職サイトやSNSで採用担当者や知人を装って接触し、マルウェア入りの資料を送りつける事例もあります。こうした「人をだます」手口全体はソーシャルエンジニアリングと呼ばれ、電話で情報を聞き出す、肩越しに画面をのぞく(ショルダーハッキング)、ごみ箱の書類をあさる(スキャベンジング/トラッシング)といった非IT的な手口も含みます。
組織としての対応は三つに整理できます。第一に、疑わしいメールを開く前に相談・報告できる窓口を決め、「報告した人を責めない」文化を作ること。第二に、開いてしまった後の手順(LANケーブルを抜く・無線を切る、電源は落とさずに情報システム部門へ連絡する)を全員が知っていること。第三に、標的型攻撃メール訓練を定期的に行い、開封率そのものより報告率と報告までの時間を評価指標にすることです。
| 区分 | 攻撃 | 何が起きるか | 見分け方・組織としての対応 |
|---|---|---|---|
| メール型 | 標的型攻撃(やり取り型) | 業務を装った添付やリンクで侵入し情報を盗む | 取引先名でも添付を開く前に相談。報告窓口と非懲罰の文化を作る |
| Web型 | 水飲み場型攻撃 | よく見るサイトを閲覧しただけで感染する | メール対策では防げない。OSとブラウザの更新、EDR等で検知する |
| 誘導型 | フィッシング | 偽サイトでIDやパスワードを入力させ盗む | メール内リンクではなくブックマークや公式アプリから開く |
| 誘導型 | スミッシング | SMSの短縮URLで偽サイトへ誘導する | 宅配や銀行の通知はSMSのリンクを踏まず公式アプリで確認する |
| 送金型 | ビジネスメール詐欺(BEC) | 偽口座へ送金させる。マルウェアを使わない | 振込先変更は登録済み電話番号へ架電して確認。高額は複数承認 |
| 詐称型 | なりすましメール | 送信者アドレスを偽装し信用させる | SPF・DKIM・DMARCで受信側が検知・遮断する |
| 画面型 | 偽の警告(サポート詐欺) | 偽警告と警告音で電話させ遠隔操作や金銭を奪う | 電話しない。画面を閉じるかブラウザを終了し情報システム部門へ報告 |
| 調査型 | SNSを使った攻撃 | 公開情報から所属や案件を集め攻撃の精度を上げる | 業務情報の投稿ルールを定め、面識のない接触は所属に確認する |
- 標的型攻撃
- 特定の組織や個人を狙い、業務に関係ありそうな件名と添付ファイルのメールなどで侵入し、情報を盗み出す攻撃。実在の担当者名や案件名が使われるため、文面だけで見抜くのは難しい。
- やり取り型攻撃
- 標的型攻撃のうち、いきなり攻撃せず、問合せなど無害なメールを何度か交わして相手の警戒を解いたうえで、マルウェア付きの添付ファイルを送りつける手口。
- 水飲み場型攻撃
- 標的が日常的に閲覧するWebサイトを事前に改ざんしておき、標的がアクセスしただけでマルウェアに感染させる攻撃。メールを使わないため、メール対策だけでは防げない。
- フィッシング
- 実在の企業や社内システムを装ったメールなどで偽サイトへ誘導し、IDやパスワード、カード番号を入力させて盗む攻撃。誘導先のURLが正規のものかを確認することが基本の防御になる。
- スミッシング
- SMS(ショートメッセージ)を使うフィッシング。宅配の不在通知や金融機関の通知を装い、短いURLで偽サイトへ誘導する。差出人表示を偽装され本物のスレッドに紛れ込むことがある。
- ビジネスメール詐欺(BEC)
- 経営者や取引先になりすましたメールで経理担当者をだまし、偽の口座へ送金させる詐欺。マルウェアを使わないためウイルス対策では防げず、振込先変更の電話確認など業務手順で防ぐ。
- 偽の警告(サポート詐欺)
- Web閲覧中に「ウイルスに感染」という偽の警告画面と警告音を出し、記載の電話番号へ電話させて遠隔操作ソフトの導入や金銭の支払いをさせる手口。画面を閉じ、電話しないのが正しい対応。
- ソーシャルエンジニアリング
- 技術ではなく人の心理や行動の隙を突いて情報を得る手口の総称。電話でのなりすまし、ショルダーハッキング(のぞき見)、スキャベンジング(ごみあさり)などが含まれる。
- 送信ドメイン認証(SPF・DKIM・DMARC)
- メールの送信元ドメインが詐称されていないかを受信側で検証する仕組み。なりすましメールの検知・遮断に有効で、DMARCは検証に失敗したメールの扱い方針を宣言できる。
例題 取引先の担当者名で「先日の見積の件」という件名のメールが届き、パスワード付きZIPが添付されていた。開く前に確認すべきことは何か。
メールに書かれた連絡先ではなく、こちらが既に持っている取引先の電話番号に架電して送付の事実を確認する。メール内の署名や返信先はいくらでも偽装できるため、確認手段は必ず別経路(アウトオブバンド)にする。判断に迷う時点で情報システム部門へ相談するのが組織としての正解。
例題 Web閲覧中に警告音とともに「ウイルスに感染しました。表示の番号に至急お電話ください」と出た。取るべき行動は。
電話しない。これは単なるWebページで、電話するとサポートを装って遠隔操作ソフトを入れられたり金銭を要求されたりする。ブラウザを終了させ(閉じられなければタスクマネージャなどで終了)、情報システム部門へ報告する。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類1 情報セキュリティ(攻撃手法・ソーシャルエンジニアリング)
認証を破る攻撃
パスワードやセッションを狙う攻撃を整理し、どの攻撃にどの対策が効くのかを対応づけて覚えます。
認証を破る攻撃は「パスワードそのものを当てにいく攻撃」と「認証を通った後の状態を乗っ取る攻撃」に大きく分かれます。名前が似ているものが多く、試験でも取り違えを狙って並べられます。仕組みの細部よりも、どの攻撃にどの対策が効くのかという対応関係で覚えるのが近道です。
ブルートフォース攻撃(総当たり攻撃)は、一つのIDに対して考えられるパスワードを片端から試す攻撃です。辞書攻撃は、辞書に載っている単語やよく使われる文字列を試す攻撃で、総当たりより効率よく当てにいきます。これらに効くのは、一定回数連続で失敗したらそのアカウントを一時的に使えなくするアカウントロックです。
リバースブルートフォース攻撃は、逆にパスワードを一つ固定し、IDのほうを次々に変えて試す攻撃です。個々のIDから見れば失敗は1回なので、アカウントロックでは止まりません。パスワードスプレー攻撃も考え方は同じで、「Password1」のようなありがちなパスワードを多数のIDに少しずつ、間隔を空けて試すため、ロックのしきい値に達しないまま侵入されます。これらには、多要素認証や、同一IPからの試行の監視、ログイン失敗の全体傾向の監視が効きます。
パスワードリスト攻撃は、どこか別のサービスから流出したIDとパスワードの組をそのまま使って、他のサービスへログインを試みる攻撃です。試すのは正しい組合せなので、パスワードが複雑でも、複雑なまま使い回していれば突破されます。原因は利用者のパスワードの使い回しであり、対策も使い回しをやめること、そして多要素認証です。パスワードを長く複雑にするだけでは防げない、という点がこの攻撃の核心です。
レインボーテーブル攻撃は、パスワードのハッシュ値と元の文字列の対応表をあらかじめ用意しておき、盗んだハッシュ値から元のパスワードを高速に割り出す攻撃です。対策は、パスワードごとに異なるランダムな文字列(ソルト)を加えてからハッシュ化し、さらにハッシュ計算を何度も繰り返す(ストレッチング)ことです。ソルトが付くと利用者ごとに結果が変わるため、汎用の対応表が使えなくなります。
認証後を狙う攻撃も押さえます。セッションハイジャックは、ログイン中の利用者に割り当てられたセッションIDを推測または盗み取り、その利用者になりすまして操作する攻撃です。クッキーの盗用はその代表的な手段で、XSSなどでクッキーを盗めばパスワードを知らなくても入り込めます。対策はクッキーにHttpOnly属性やSecure属性を付ける、通信全体をTLSで暗号化する、ログイン成功時にセッションIDを再発行することです。
中間者攻撃(MITM)は、通信する二者の間に割り込んで内容を盗み見たり書き換えたりする攻撃です。公衆無線LANでの盗聴や、偽アクセスポイントを立てる手口が典型です。対策はTLSによる暗号化と、サーバ証明書の警告を無視しないことです。リプレイ攻撃は、盗み見た認証データをそのまま再送して認証を通ってしまう攻撃で、対策には一度限りの乱数(ワンタイムのチャレンジ)やワンタイムパスワード、タイムスタンプを使います。
情報セキュリティリーダーの立場では、これらを個別に暗記するよりも「アカウントロックが効く攻撃と効かない攻撃がある」「使い回しをやめないと防げない攻撃がある」「最終的な共通解は多要素認証」という三点を職場に説明できることが重要です。
| 区分 | 攻撃 | 何が起きるか | 効く対策 | 効かない対策 |
|---|---|---|---|---|
| パスワードを当てる | ブルートフォース攻撃 | 1つのIDに全パターンを試される | アカウントロック、長く複雑なパスワード | 使い回しの禁止だけでは不十分 |
| パスワードを当てる | 辞書攻撃 | 辞書語やありがちな文字列を試される | アカウントロック、推測しやすい語の禁止 | パスワードの定期変更 |
| パスワードを当てる | リバースブルートフォース攻撃 | パスワードを固定しIDを変えて試される | 多要素認証、試行元IPの監視 | アカウントロック(各IDの失敗は1回) |
| パスワードを当てる | パスワードスプレー攻撃 | ありがちな語を多数のIDへ少しずつ試される | 多要素認証、失敗の全体傾向の監視 | アカウントロック(しきい値に達しない) |
| 正解を使い回す | パスワードリスト攻撃 | 他社で流出した正しい組でログインされる | 使い回しの禁止、多要素認証 | 複雑なパスワードにするだけ |
| ハッシュを解く | レインボーテーブル攻撃 | 盗んだハッシュ値から元の文字列を割り出される | ソルト+ストレッチング | アカウントロック |
| 認証後を奪う | セッションハイジャック/クッキーの盗用 | ログイン中の状態を乗っ取られる | HttpOnly・Secure属性、TLS、ID再発行 | パスワードの複雑化 |
| 通信に割り込む | 中間者攻撃(MITM) | 通信を盗み見・改ざんされる | TLS暗号化、証明書警告を無視しない | アカウントロック |
| 通信を再送する | リプレイ攻撃 | 盗んだ認証データの再送で認証を通される | ワンタイムパスワード、乱数、タイムスタンプ | パスワードの複雑化 |
- ブルートフォース攻撃
- 一つのIDに対して、考えられるパスワードを片端から試して当てる総当たり攻撃。連続失敗でアカウントを一時的に無効化するアカウントロックが有効な対策になる。
- 辞書攻撃
- 辞書の単語やよく使われる文字列をパスワード候補として試す攻撃。総当たりより少ない試行で当たりやすいため、推測されやすい語をパスワードに使わないことも防御になる。
- パスワードリスト攻撃
- 他のサービスから流出したIDとパスワードの組を、別のサービスでそのまま試す攻撃。原因は利用者による使い回しであり、複雑なパスワードにしても使い回していれば防げない。
- リバースブルートフォース攻撃
- パスワードを一つ固定し、IDのほうを次々に変えて試す攻撃。各IDの失敗は1回ずつなのでアカウントロックでは止まらず、多要素認証や試行元の監視で対処する。
- パスワードスプレー攻撃
- ありがちなパスワードを多数のIDに対して、間隔を空けながら少しずつ試す攻撃。ロックのしきい値に達しないよう調整されるため、ログイン失敗の全体傾向の監視が必要になる。
- レインボーテーブル攻撃
- ハッシュ値と元の文字列の対応表を使い、盗んだハッシュ値から元のパスワードを高速に割り出す攻撃。利用者ごとに異なるソルトを加えてハッシュ化することで無効化できる。
- ソルトとストレッチング
- ソルトはパスワードごとに加える異なるランダム文字列で、同じパスワードでもハッシュ値が変わる。ストレッチングはハッシュ計算を何度も繰り返して総当たりの時間を稼ぐ手法。
- セッションハイジャック
- ログイン中の利用者のセッションIDを推測または盗み、その利用者になりすまして操作する攻撃。クッキーの属性設定、通信の暗号化、ログイン時のセッションID再発行で防ぐ。
- 中間者攻撃(MITM)
- 通信する二者の間に割り込み、内容を盗み見たり書き換えたりする攻撃。公衆無線LANや偽アクセスポイントで起きやすく、TLSによる暗号化と証明書の警告を無視しない運用で防ぐ。
- リプレイ攻撃
- 盗聴した認証データをそのまま再送して認証を通す攻撃。パスワードの中身が分からなくても成立するため、ワンタイムパスワードや一度限りの乱数、タイムスタンプで無効化する。
例題 自社サービスで、正しいIDとパスワードの組による不正ログインが多数発生した。パスワードはいずれも十分に複雑だった。最も疑うべき攻撃と、利用者に依頼すべきことは何か。
パスワードリスト攻撃。他サービスから流出した組が使い回されている。利用者には他サービスと同じパスワードを使わないよう依頼し、あわせて多要素認証を導入する。パスワードをさらに複雑にしても、使い回している限り防げない。
例題 アカウントロックを導入済みなのに、ロックが一度も作動しないまま不正ログインされた。考えられる攻撃は。
パスワードスプレー攻撃やリバースブルートフォース攻撃。1つのIDあたりの失敗回数がしきい値に届かないため、ロックが働かない。個別アカウントではなく、全体のログイン失敗の傾向や試行元IPを監視し、多要素認証を導入する。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類1 情報セキュリティ(攻撃手法・利用者認証)
Webとシステムを狙う攻撃
SQLインジェクションやXSSなどWebの代表的な攻撃と、それぞれに対応する正しい対策を結び付けます。
Webサイトやシステムを狙う攻撃は、入力欄やURLに細工した文字列を送り込み、本来意図していない動作をさせるものが中心です。情報セキュリティリーダーは自分でプログラムを直すわけではありませんが、「この被害はどの攻撃で、開発ベンダに何を直してもらうべきか」を判断できる必要があります。攻撃と対策は一対一に近い形で決まっているので、その対応を覚えることが要点です。
SQLインジェクションは、入力欄に細工した文字列を入れることでデータベースへの命令(SQL文)を書き換え、本来見えないはずのデータを取り出したり、データを改ざん・削除したりする攻撃です。会員情報の大量流出につながる代表的な攻撃で、正しい対策はプレースホルダ(バインド機構)を使ってSQL文を組み立てることです。入力値を文字列としてつなぎ合わせるのをやめれば、入力が命令として解釈されなくなります。エスケープ処理も次善の策ですが、根本的な対策はプレースホルダです。
クロスサイトスクリプティング(XSS)は、掲示板や検索結果など、利用者の入力をそのまま画面に表示するページの脆弱性を突き、悪意のあるスクリプトを他の利用者のブラウザ上で実行させる攻撃です。被害はクッキーの盗用によるセッションハイジャックや、偽の入力フォームの表示です。対策は、画面に出力するときにエスケープ処理を行い、記号をスクリプトとして解釈されない形に変換することです。
クロスサイトリクエストフォージェリ(CSRF)は、ログイン中の利用者に細工したリンクを踏ませることで、その利用者の権限で意図しない処理(退会、設定変更、掲示板への書き込みなど)を実行させる攻撃です。利用者本人の正規のセッションが使われるため、入力値の検証では防げません。対策は、処理を受け付けるページごとに推測できないトークンを埋め込み、送られてきたトークンが正しいことを確認することです。
ディレクトリトラバーサルは、ファイル名を指定するパラメータに「../」のような相対パスを混ぜ込み、公開が想定されていない上位ディレクトリのファイル(設定ファイルやパスワードファイル)を読み出す攻撃です。対策は、利用者からファイル名を直接受け取らない設計にすること、受け取る場合は入力値の検証で許可した文字や名前だけを通すことです。
OSコマンドインジェクションは、Webアプリが内部でOSのコマンドを呼び出している箇所に細工した文字列を送り込み、サーバ上で任意のコマンドを実行させる攻撃です。サーバそのものを乗っ取られる危険があります。対策は、OSコマンドを呼び出す処理を避けること、避けられない場合は入力値を厳密に検証することです。
バッファオーバフローは、プログラムが用意したメモリ領域を超える大きさのデータを送り込み、あふれさせて動作を乗っ取る攻撃です。対策はプログラム側で入力データの長さを検査することと、修正プログラム(パッチ)の適用です。クリックジャッキングは、透明にした別のページを本物の画面に重ね、利用者が押したつもりのない場所をクリックさせる攻撃で、対策は自サイトを他サイトの枠内に表示させない設定です。
ドライブバイダウンロードは、改ざんされたWebサイトを閲覧しただけで、利用者が気づかないうちにマルウェアをダウンロード・実行させる攻撃です。水飲み場型攻撃の実行手段としても使われます。利用者側の対策は、OS・ブラウザ・各種ソフトウェアを最新の状態に保つことに尽きます。
| 区分 | 攻撃 | 何が起きるか | 対応する対策 |
|---|---|---|---|
| データベース | SQLインジェクション | データベースの命令を書き換えられ会員情報などが流出する | プレースホルダ(バインド機構)でSQL文を組み立てる |
| ブラウザ | クロスサイトスクリプティング(XSS) | 他の利用者のブラウザで悪意のスクリプトが動きクッキーを盗まれる | 出力時のエスケープ処理 |
| ブラウザ | クロスサイトリクエストフォージェリ(CSRF) | ログイン中の利用者の権限で意図しない処理が実行される | 推測できないトークンの埋込みと照合 |
| ブラウザ | クリックジャッキング | 透明な画面を重ねられ意図しない場所をクリックさせられる | 他サイトの枠内に自サイトを表示させない設定 |
| ファイル | ディレクトリトラバーサル | 公開対象外の上位ディレクトリのファイルを読み出される | ファイル名を直接受け取らない設計と入力値の検証 |
| サーバ | OSコマンドインジェクション | サーバ上で任意のコマンドを実行され乗っ取られる | OSコマンド呼出しの回避と入力値の厳密な検証 |
| サーバ | バッファオーバフロー | メモリをあふれさせられプログラムの動作を乗っ取られる | 入力データ長の検査とパッチの適用 |
| 利用者端末 | ドライブバイダウンロード | 改ざんサイトを見ただけでマルウェアを実行させられる | OS・ブラウザ・ソフトウェアを最新に保つ |
- SQLインジェクション
- 入力欄に細工した文字列を入れてデータベースへの命令を書き換え、非公開データの取得や改ざん・削除を行う攻撃。プレースホルダ(バインド機構)でSQL文を組み立てるのが根本対策。
- プレースホルダ(バインド機構)
- SQL文の可変部分をあらかじめ記号で確保しておき、後から値だけを当てはめる仕組み。入力が命令として解釈されなくなるため、SQLインジェクションの根本的な対策になる。
- クロスサイトスクリプティング(XSS)
- 利用者の入力をそのまま表示するページの弱点を突き、他の利用者のブラウザ上で悪意のスクリプトを実行させる攻撃。出力時のエスケープ処理が対策で、クッキーの盗用につながる。
- エスケープ処理(サニタイジング)
- 画面に出力する文字列のうち、記号など特別な意味を持つ文字を無害な表記に変換する処理。XSSの対策として、利用者の入力を表示するすべての箇所で行う必要がある。
- クロスサイトリクエストフォージェリ(CSRF)
- ログイン中の利用者に細工したリンクを踏ませ、その人の権限で意図しない処理を実行させる攻撃。推測できないトークンをページに埋め込み、送信時に照合することで防ぐ。
- ディレクトリトラバーサル
- ファイル名の指定に「../」などを混ぜ、公開対象外の上位ディレクトリにあるファイルを読み出す攻撃。利用者からファイル名を直接受け取らない設計と入力値の検証で防ぐ。
- OSコマンドインジェクション
- Webアプリが内部で呼び出すOSコマンドに細工した文字列を送り込み、サーバ上で任意のコマンドを実行させる攻撃。サーバ乗っ取りに直結するため入力値の厳密な検証が必要。
- バッファオーバフロー
- プログラムが確保したメモリ領域を超えるデータを送ってあふれさせ、プログラムの動作を乗っ取る攻撃。入力データ長の検査と、修正プログラム(パッチ)の適用で防ぐ。
- クリックジャッキング
- 透明にした別ページを本物の画面に重ね、利用者が意図しない場所をクリックさせて操作を実行させる攻撃。自サイトを他サイトの枠内に表示させない設定で防ぐ。
- ドライブバイダウンロード
- 改ざんされたWebサイトを閲覧しただけで、気づかないうちにマルウェアをダウンロード・実行させる攻撃。OSやブラウザ、各種ソフトを最新に保つことが利用者側の対策になる。
例題 自社の会員サイトから会員のメールアドレスと住所が大量に流出した。調査で、検索画面の入力欄に細工した文字列が送られていたことが分かった。開発ベンダに求めるべき修正は何か。
SQLインジェクションの疑いが強く、プレースホルダ(バインド機構)を用いてSQL文を組み立てるよう求める。エスケープ処理はXSS、トークンはCSRF、アカウントロックはブルートフォース攻撃への対策であり、この被害には対応しない。
例題 ログイン中の利用者がメール内のリンクを踏んだだけで、本人の意図しない退会処理が実行された。どの攻撃で、対策は何か。
クロスサイトリクエストフォージェリ(CSRF)。利用者本人の正規のセッションが悪用されるため、入力値の検証やエスケープ処理では防げない。処理画面に推測できないトークンを埋め込み、送信されたトークンを照合する。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類1 情報セキュリティ(攻撃手法・Webアプリケーションの脆弱性)
サービスを止める・広げる攻撃
DDoSや偽装系の攻撃、そしてサプライチェーン攻撃やAI悪用など、被害が外へ広がる攻撃を押さえます。
ここでは、情報を盗むのではなく「サービスを止める」攻撃と、被害が自社の外へ広がっていく攻撃を扱います。前者は事業継続の問題、後者は取引先や顧客への責任の問題であり、いずれも情報セキュリティリーダーが経営層へ説明する場面の多いテーマです。
DoS攻撃(サービス妨害攻撃)は、大量の通信や処理要求を送りつけてサーバやネットワークを過負荷にし、正規の利用者がサービスを使えない状態にする攻撃です。狙われるのは可用性です。DDoS攻撃(分散型サービス妨害攻撃)は、これを多数の機器から一斉に行うもので、あらかじめマルウェアに感染させて外部から操れるようにした多数の端末(ボットネット)が使われます。送信元が世界中に分散するため、単純に送信元IPアドレスを遮断する対処では追いつきません。近年は監視カメラやルータなどのIoT機器が踏み台にされ、自社の機器が知らないうちに加害者側になる点も重要です。
DNSリフレクション攻撃(DNSアンプ攻撃)は、送信元IPアドレスを標的のものに偽装した小さな問合せを多数のDNSサーバへ送り、大きな応答を標的へ集中させる攻撃です。少ない通信量で大きな攻撃を作り出せるため「増幅(アンプ)」と呼ばれます。SYN Flood攻撃は、接続要求だけを大量に送り、応答を返さずに接続待ちの状態を積み上げてサーバの資源を使い切らせる攻撃です。F5アタックは、ブラウザの再読込みキー(F5)を連打するなどして同じページの読込みを繰り返させる、単純な負荷攻撃です。
偽装によって通信をだます攻撃も整理しておきます。DNSキャッシュポイズニングは、DNSサーバのキャッシュに偽の対応情報を覚えさせ、正しいURLを入力した利用者を偽サイトへ誘導する攻撃です。利用者側からは正しいアドレスを打っているため気づきにくいのが厄介です。ARPスプーフィングは、同じLAN内でMACアドレスの対応を偽って通知し、通信を自分の機器へ引き込む攻撃で、中間者攻撃の足がかりになります。IPスプーフィングは送信元IPアドレスを偽装する手口で、DoSの発信元隠しやアクセス制限の回避に使われます。
ゼロデイ攻撃は、脆弱性が公表されてから修正プログラムが提供されるまでの間、あるいは開発者がまだ気づいていない段階で、その脆弱性を突く攻撃です。パッチが存在しないため「更新すれば防げる」という前提が通用せず、多層防御や振る舞い検知、侵入を前提とした検知・対応の体制が必要になります。
サプライチェーン攻撃は、狙った大企業を直接攻めるのではなく、防御の手薄な取引先や子会社、あるいは広く使われているソフトウェアの提供元を侵害し、そこを経由して本命に到達する攻撃です。自社の対策が万全でも、委託先経由で情報が漏れれば責任は自社にも及びます。対策は、委託先の選定基準に情報セキュリティ要件を含めること、契約で再委託や報告義務を定めること、定期的に委託先の管理状況を確認すること、といった委託先管理そのものです。
クリプトジャッキングは、他人のパソコンやサーバに無断で暗号資産のマイニング(採掘)を行うプログラムを仕込み、その計算能力を勝手に使う攻撃です。情報が盗まれるわけではないため気づきにくく、動作が急に重くなる、電気代やクラウド利用料が跳ね上がるといった形で表れます。
AIを悪用した攻撃も現実の脅威になっています。ディープフェイクは、AIで本物そっくりの映像や音声を作り出すもので、経営者の声を合成して電話で送金を指示する事例が報告されています。生成AIによってフィッシングメールの文面が自然な日本語になり、「日本語が不自然だから偽物」という従来の見分け方が通用しなくなりました。したがって、文面の巧拙で判断するのをやめ、送金や権限変更は必ず定められた手順と別経路の確認を通す、という業務ルールの徹底がいっそう重要になります。
| 区分 | 攻撃 | 何が起きるか | 組織としての備え |
|---|---|---|---|
| サービス妨害 | DoS攻撃 | 過負荷で正規利用者がサービスを使えなくなる(可用性) | 帯域と処理能力の確保、監視と連絡体制の整備 |
| サービス妨害 | DDoS攻撃 | 多数の踏み台から一斉に攻撃され送信元遮断が効かない | DDoS対策サービスの利用、自社IoT機器の初期パスワード変更 |
| サービス妨害 | DNSリフレクション(アンプ)攻撃 | 送信元を偽装した問合せの大きな応答が標的に集中する | DNSサーバを外部から自由に使えない設定にする |
| サービス妨害 | SYN Flood攻撃 | 接続待ち状態を積み上げられサーバの資源が尽きる | 接続数の制限、機器やOSの設定と更新 |
| サービス妨害 | F5アタック | 再読込みの連打で同じページの読込みが繰り返される | 同一送信元からの過剰なリクエストの制限 |
| 偽装 | DNSキャッシュポイズニング | 正しいURLを入力しても偽サイトへ誘導される | DNSサーバの更新と適切な設定、DNSSECの利用 |
| 偽装 | ARPスプーフィング | 同一LAN内で通信を引き込まれ盗聴・改ざんされる | 通信の暗号化、不審な機器の接続監視 |
| 偽装 | IPスプーフィング | 送信元IPを偽られ攻撃元の特定や制限を逃れられる | 送信元IPだけに依存しない認証・アクセス制御 |
| 拡大・新種 | ゼロデイ攻撃 | 修正プログラムがない期間に脆弱性を突かれる | 多層防御、振る舞い検知、侵入を前提とした対応体制 |
| 拡大・新種 | サプライチェーン攻撃 | 取引先や提供元を経由して本命の組織が侵害される | 委託先の選定基準・契約条項・定期的な管理状況の確認 |
| 拡大・新種 | クリプトジャッキング | 計算能力を無断でマイニングに使われる | 動作の重さやクラウド利用料の異常な増加を監視する |
| 拡大・新種 | AIの悪用(ディープフェイク等) | 合成音声での送金指示や自然な文面のフィッシングが届く | 文面や声で判断せず、別経路の確認と多人数承認を必須にする |
- DoS攻撃
- 大量の通信や処理要求を送りつけてサーバやネットワークを過負荷にし、正規の利用者がサービスを利用できない状態にする攻撃。侵害される情報セキュリティの要素は可用性である。
- DDoS攻撃
- マルウェアに感染させた多数の機器(ボットネット)から一斉にDoS攻撃を行うもの。送信元が分散するため単純な送信元遮断では対処できず、自社機器が踏み台にされる恐れもある。
- DNSリフレクション攻撃(DNSアンプ攻撃)
- 送信元IPアドレスを標的に偽装した小さな問合せを多数のDNSサーバへ送り、大きな応答を標的に集中させる攻撃。少ない通信量で大きな攻撃量を作り出せる点が特徴。
- SYN Flood攻撃
- 接続要求だけを大量に送り、応答を返さないことで接続待ちの状態を積み上げ、サーバの資源を使い切らせるDoS攻撃の一種。通信量が少なくても成立する。
- DNSキャッシュポイズニング
- DNSサーバのキャッシュに偽のアドレス情報を覚えさせ、正しいURLを入力した利用者を偽サイトへ誘導する攻撃。利用者側は正しいアドレスを入力しているため気づきにくい。
- ARPスプーフィング
- 同一LAN内でMACアドレスとIPアドレスの対応を偽って通知し、他者宛ての通信を自分の機器へ引き込む攻撃。中間者攻撃による盗聴や改ざんの足がかりとして使われる。
- IPスプーフィング
- パケットの送信元IPアドレスを偽装する手口。攻撃元の隠蔽、送信元IPアドレスによるアクセス制限の回避、リフレクション攻撃の踏み台化などに利用される。
- ゼロデイ攻撃
- 脆弱性の修正プログラムが提供される前の期間に、その脆弱性を突く攻撃。パッチ適用では防げないため、多層防御や振る舞い検知、侵入を前提とした検知・対応体制が必要になる。
- サプライチェーン攻撃
- 防御の手薄な取引先や子会社、ソフトウェアの提供元を侵害し、そこを経由して本命の組織へ到達する攻撃。委託先の選定基準・契約条項・定期的な確認といった委託先管理が対策となる。
- クリプトジャッキング
- 他人の機器に無断で暗号資産のマイニングを行うプログラムを仕込み、計算能力を勝手に使う攻撃。情報流出がないため気づきにくく、動作の重さや電気代・利用料の増加で表面化する。
- ディープフェイク
- AIによって本物そっくりの映像や音声を作り出す技術、およびそれを悪用した攻撃。経営者の声を合成した電話での送金指示など、なりすましの説得力を大きく高める。
例題 自社は堅牢な対策を実施していたが、業務を委託している小規模な事務代行会社が侵害され、そこから預けていた顧客名簿が流出した。この攻撃の呼び名と、今後の対策は何か。
サプライチェーン攻撃。自社の技術的対策では防げず、委託先管理で防ぐ。委託先の選定時に情報セキュリティ要件を確認し、契約で再委託の制限・情報の取扱い・事故時の報告義務を定め、定期的に管理状況を確認する。
例題 「社長の声」で経理担当者に電話があり、緊急の送金を指示された。声は本人そっくりだった。組織として置くべき歯止めは何か。
ディープフェイクによる音声の合成が疑われる。声や文面の自然さで真偽を判断させないことが要点で、送金や振込先変更は登録済みの連絡先への折返し確認と複数人の承認を必須にする業務手順で歯止めをかける。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類1 情報セキュリティ(攻撃手法・DoS攻撃・サプライチェーンの情報セキュリティ)
暗号と認証
暗号のしくみ
共通鍵と公開鍵の違い、ハイブリッド暗号、ハッシュ関数までを一度に整理し、「どの鍵をどこで使うのか」を体で覚えます。
暗号とは、そのままでは読める情報(平文)を、鍵を使って読めない形(暗号文)に変える技術です。暗号文を平文に戻すことを復号といいます。守れるのは主に機密性で、盗み見られても中身が分からない状態をつくります。逆にいえば、暗号だけでは「誰が送ったのか」「途中で書き換えられていないか」は分かりません。それはディジタル署名やハッシュの役目です。
共通鍵暗号方式は、暗号化と復号に同じ鍵を使う方式です。代表がAESで、処理が速く、大量のデータや通信の本体を暗号化するのに向いています。弱点は鍵の配り方です。相手ごとに別の鍵を用意するため、n人が互いに通信するには n(n-1)/2 個の鍵が必要になり、人数が増えると急激に増えます。しかもその鍵を安全に相手へ届けなければならず、これを鍵配送問題といいます。
公開鍵暗号方式は、公開鍵と秘密鍵という対になった2つの鍵を使います。代表がRSAと楕円曲線暗号(ECC)です。公開鍵は誰に渡してもよく、秘密鍵は本人だけが持ちます。鍵は1人あたり2個なので、n人なら合計 2n 個で済み、鍵配送問題を解決できます。ただし計算量が大きく、共通鍵暗号よりずっと遅いのが難点です。
ここが最重要です。機密性を守るために暗号化するときは、受信者の公開鍵で暗号化し、受信者の秘密鍵で復号します。受信者の秘密鍵を持っているのは受信者だけなので、その人しか読めません。送信者の鍵は一切使いません。この向きを逆にすると、誰でも復号できてしまい意味がなくなります。
ハイブリッド暗号方式は、両方のいいとこ取りです。データ本体は速い共通鍵暗号(セッション鍵)で暗号化し、そのセッション鍵だけを受信者の公開鍵で暗号化して届けます。受信者は自分の秘密鍵でセッション鍵を取り出し、それでデータ本体を復号します。TLSやS/MIMEなど実用の暗号通信は、ほぼこの方式です。
ハッシュ関数は、任意の長さのデータから固定長の短い値(ハッシュ値、メッセージダイジェスト)を作る一方向の計算です。代表がSHA-256。元に戻せない一方向性と、同じハッシュ値になる別のデータを見つけにくい衝突困難性を持ちます。鍵を使わないので暗号化ではありません。ファイルの改ざん検知や、パスワードをそのまま保存しないための仕組みに使われます。
パスワードをハッシュ値で保存しても、よくあるパスワードは事前計算した表(レインボーテーブル)で見破られます。そこで利用者ごとに異なるランダムな文字列(ソルト)を足してからハッシュ化し、さらにハッシュ計算を数千回以上繰り返して総当たりを遅くします。この繰り返しがストレッチングです。
暗号化の対象は、保存時と通信時に分けて考えます。保存時はファイル単位の暗号化と、ディスク全体を暗号化する方式があります。ディスク全体の暗号化は、持ち出しPCの紛失・盗難時に中身を守るのに有効ですが、正規にログインした状態では復号されて読めるため、マルウェアや内部不正への対策にはなりません。通信時はTLS、VPN、無線LANのWPA3などで守ります。
暗号の強さは鍵の管理で決まります。鍵が漏れたり、計算機の性能向上で解読可能になったりして安全でなくなることを危殆化といい、鍵長を伸ばす、より新しい方式へ移行する、鍵を定期的に更新するといった対応が必要です。将来、量子コンピュータが実用化するとRSAや楕円曲線暗号が破られる恐れがあるため、それに耐える耐量子計算機暗号(PQC)への移行が国際的に進められています。
必要な鍵の数の早見表(相互に通信する場合)
利用者数 n 共通鍵 n(n-1)/2 公開鍵 2n
5 10 10
10 45 20
20 190 40
50 1225 100
100 4950 200
| 区分 | 共通鍵暗号方式 | 公開鍵暗号方式 |
|---|---|---|
| 代表的な方式 | AES | RSA、楕円曲線暗号(ECC) |
| 鍵の関係 | 暗号化と復号が同じ鍵 | 公開鍵と秘密鍵のペア(別の鍵) |
| n人が相互に通信するときの鍵の数 | n(n-1)/2 個(例 50人なら1225個) | 2n 個(例 50人なら100個) |
| 処理速度 | 速い(大量データ向き) | 遅い(小さいデータ向き) |
| 鍵配送 | 相手ごとに安全に配る必要あり(鍵配送問題) | 公開鍵は公開してよいので問題が起きにくい |
| 鍵の秘密 | 通信する両者が同じ鍵を秘密に保つ | 秘密鍵は本人だけが保管する |
| 主な使いどころ | 通信やファイルの本体の暗号化 | 鍵の受渡し、ディジタル署名 |
| ハイブリッド暗号での役割 | データ本体をセッション鍵で暗号化 | そのセッション鍵を受信者の公開鍵で暗号化 |
- 平文と暗号文
- そのまま読める元のデータが平文、鍵で変換して読めなくしたものが暗号文。暗号文を平文に戻すことを復号という。暗号が守るのは主に機密性であり、改ざんの検知や送信者の特定はできない。
- 共通鍵暗号方式
- 暗号化と復号に同じ鍵を使う方式。代表はAES。処理が速く大量データ向きだが、相手ごとに鍵が必要でn人なら n(n-1)/2 個になり、鍵を安全に届ける鍵配送問題が生じる。
- AES
- 現在の標準的な共通鍵暗号方式。鍵長は128・192・256ビットが規定されている。無線LANのWPA2/WPA3やTLSのデータ本体の暗号化など、幅広く使われている。
- 公開鍵暗号方式
- 公開鍵と秘密鍵のペアを使う方式。公開鍵は誰に配ってもよく、秘密鍵は本人だけが保管する。鍵は1人2個なのでn人でも 2n 個で足り、鍵配送問題を解決できるが、処理は共通鍵暗号より遅い。
- RSA
- 大きな数の素因数分解の難しさを安全性の根拠とする公開鍵暗号方式。暗号化にもディジタル署名にも使える。安全性を保つため鍵長を長くする必要があり、2048ビット以上が一般的になっている。
- 楕円曲線暗号(ECC)
- 楕円曲線上の計算の難しさを利用した公開鍵暗号方式。RSAより短い鍵長で同等の強度が得られるため、処理や通信量を抑えられ、スマートフォンやICカードなど資源の少ない機器で広く使われる。
- ハイブリッド暗号方式
- データ本体は速い共通鍵暗号で暗号化し、その共通鍵(セッション鍵)だけを受信者の公開鍵で暗号化して渡す方式。速度と鍵配送の両方の問題を解決でき、TLSやS/MIMEで使われている。
- ハッシュ関数
- 任意長のデータから固定長のハッシュ値を作る一方向の計算。元に戻せない一方向性と、同じ値になる別データを見つけにくい衝突困難性を持つ。鍵を使わないため暗号化ではなく、改ざん検知やパスワード保存に使う。
- SHA-256
- 256ビットのハッシュ値を出力する代表的なハッシュ関数。ファイルの改ざん検知やディジタル署名の前処理に使われる。かつて広く使われたMD5やSHA-1は衝突が見つかっており、新規の利用は推奨されない。
- ソルト
- パスワードをハッシュ化する前に付け加える、利用者ごとに異なるランダムな文字列。同じパスワードでも保存されるハッシュ値が変わるため、事前計算した表(レインボーテーブル)による解読を防げる。
- ストレッチング
- ハッシュ計算を数千回から数万回繰り返して、1回の照合にわざと時間をかける手法。利用者の待ち時間はわずかだが、攻撃者の総当たり攻撃は現実的でなくなる。ソルトと組み合わせて使う。
- ディスク暗号化
- 記憶装置全体を暗号化し、起動時の認証を通らなければ読めなくする方式。ノートPCやUSBメモリの紛失・盗難対策に有効。ただし正規にログインした後は復号されるため、マルウェアや内部不正の対策にはならない。
- 危殆化
- 鍵の漏えいや計算機の性能向上、方式の弱点発見によって、暗号が安全でなくなること。鍵長を伸ばす、より新しい方式へ移行する、鍵を定期的に更新するといった対応で備える。
- 耐量子計算機暗号(PQC)
- 量子コンピュータが実用化してもRSAや楕円曲線暗号のようには破られないと考えられている暗号方式の総称。今の暗号文を保存しておいて将来解読される恐れがあるため、早期の移行が国際的に検討されている。
例題 社員10人が互いに共通鍵暗号で通信する。必要な鍵は何個か。また同じ10人が公開鍵暗号を使う場合は何個か。
共通鍵は 10×9÷2 = 45個。公開鍵暗号は1人が公開鍵と秘密鍵の2個を持つので 2×10 = 20個。人数が増えるほど共通鍵の方が急増する(100人なら4950個対200個)。
例題 AさんがBさんにだけ読める文書を送りたい。誰のどの鍵で暗号化し、誰のどの鍵で復号するか。
Bさん(受信者)の公開鍵で暗号化し、Bさん(受信者)の秘密鍵で復号する。Bさんの秘密鍵を持つのはBさんだけなので、他人には読めない。Aさん自身の鍵は使わないことに注意。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類1 情報セキュリティ(暗号技術)/JIS Q 27000 用語
ディジタル署名と証明書
「本人が書いた」「書き換えられていない」を証明する仕組みと、その土台になる証明書・認証局の役割をつかみます。
暗号は中身を隠す技術でしたが、業務では「本当にこの人が送ったのか」「途中で書き換えられていないか」を確かめたい場面が多くあります。それを実現するのがディジタル署名です。ハッシュ関数と公開鍵暗号方式を組み合わせて作ります。
作り方はこうです。送信者は文書のハッシュ値を求め、それを自分(送信者)の秘密鍵で変換します。これが署名です。受信者は受け取った文書から同じようにハッシュ値を計算し、送られてきた署名を送信者の公開鍵で変換した値と比べます。一致すれば、署名は確かに送信者の秘密鍵で作られたもので、文書も書き換えられていないと分かります。
鍵の向きが暗号化とちょうど逆になっている点が最大のポイントです。機密性のための暗号化は受信者の公開鍵で行い受信者の秘密鍵で復号しますが、ディジタル署名は送信者の秘密鍵で行い送信者の公開鍵で検証します。試験ではここを入れ替えた選択肢が必ず出ます。「隠すときは相手の鍵、名乗るときは自分の鍵」と覚えると混乱しません。
署名で分かるのは、改ざんの検知(完全性)、送信者が本人であること(真正性)、あとから「送っていない」と言わせない否認防止の3つです。分からないのは機密性です。署名を付けても文書そのものは平文のままなので、盗み見は防げません。中身も隠したいなら、署名に加えて受信者の公開鍵で暗号化する必要があります。
メッセージ認証符号(MAC)は、送受信者が共有する秘密鍵とハッシュ関数で作る検証用の値です。改ざんの検知と相手の確認はできますが、同じ鍵を両者が持っているため、受信者にも同じ値が作れてしまい、否認防止はできません。否認防止まで必要ならディジタル署名を使います。
ディジタル署名の検証には送信者の公開鍵が要りますが、その公開鍵が本当に本人のものかは、公開鍵そのものからは分かりません。そこで信頼できる第三者である認証局(CA)が、公開鍵と持ち主の情報をまとめてCAの秘密鍵で署名した、ディジタル証明書(公開鍵証明書)を発行します。この仕組み全体をPKI(公開鍵基盤)といいます。
証明書はCAがCAを保証する連鎖(証明書チェーン)になっており、その頂点にあるのがルート証明書です。ルート証明書は自分自身で署名した自己署名証明書で、OSやブラウザにあらかじめ組み込まれた信頼の起点です。したがって、素性の分からないルート証明書を安易にインストールしてはいけません。
秘密鍵の漏えいや退職などで証明書を有効期限前に無効にすることを失効といいます。失効した証明書の一覧が失効リスト(CRL)で、リストを丸ごと取得する代わりに1件ずつ問い合わせて状態を確かめる方式がOCSPです。証明書は有効期限だけでなく、失効していないかの確認も必要です。
タイムスタンプは、時刻認証局(TSA)が「その時刻にその電子データが存在し、以後変更されていない」ことを証明する仕組みです。署名した本人の証明である電子署名に、いつの話かという時点の証明を足す役目があり、電子署名法では一定の要件を満たす電子署名に手書きの署名や押印と同じ効力を認めています。
Webの通信で使われるTLS(旧称SSL)は、これらの技術の集大成です。サーバのディジタル証明書でサーバが本物か確かめ、公開鍵暗号でセッション鍵を安全に共有し、その後は共通鍵暗号で高速に通信します。HTTPをTLSで保護したものがHTTPSです。サーバ証明書には、ドメイン名だけを確認するDV、組織の実在も確認するOV、より厳格な審査を行うEVがあり、EVでも通信の暗号強度が上がるわけではなく、確認される相手の身元の厳しさが違う点に注意します。
| 目的 | 送信者Aがすること | 受信者Bがすること | 守れるもの |
|---|---|---|---|
| 機密性を守る(暗号化) | 受信者Bの公開鍵で暗号化 | 受信者Bの秘密鍵で復号 | 盗み見の防止(機密性) |
| 本人性・完全性(ディジタル署名) | 送信者Aの秘密鍵で署名 | 送信者Aの公開鍵で検証 | 改ざんの検知・本人性・否認防止 |
| 両方(署名付き暗号メール) | Aの秘密鍵で署名し、Bの公開鍵で暗号化 | Bの秘密鍵で復号し、Aの公開鍵で検証 | 機密性+改ざんの検知+否認防止 |
| 鍵の受渡し(ハイブリッド暗号) | 受信者Bの公開鍵でセッション鍵を暗号化 | 受信者Bの秘密鍵でセッション鍵を復号 | 共通鍵を安全に届ける |
| MAC(共通鍵方式) | AとBで共有した秘密鍵でMACを生成 | 同じ共有秘密鍵でMACを検証 | 改ざんの検知(否認防止は不可) |
| 証明書の信頼 | 認証局CAの秘密鍵で証明書に署名 | CAの公開鍵(ルート証明書)で検証 | 公開鍵の持ち主が本人であること |
- ディジタル署名
- 文書のハッシュ値を送信者の秘密鍵で変換して付ける値。受信者は送信者の公開鍵で検証する。改ざんの検知・本人性・否認防止を実現するが、文書自体は平文のままなので機密性は守れない。
- 否認防止
- あとから「自分は送っていない」「そんな取引はしていない」と言い逃れできないようにすること。秘密鍵は本人しか持たないため、ディジタル署名で実現できる。共有鍵を使うMACでは実現できない。
- メッセージ認証符号(MAC)
- 送受信者が共有する秘密鍵とハッシュ関数から作る検証値。改ざんの検知はできるが、受信者も同じ鍵で同じ値を作れるため否認防止はできない。処理が軽く、通信プロトコルの中で広く使われる。
- PKI(公開鍵基盤)
- 公開鍵が確かに本人のものであることを、認証局と証明書によって保証する社会的な仕組みの総称。証明書の発行・更新・失効の運用まで含む。TLSや電子契約の土台になっている。
- 認証局(CA)
- 申請者の身元を確認し、公開鍵と持ち主の情報に自らの秘密鍵で署名してディジタル証明書を発行する信頼される第三者。証明書の失効情報の公開も担う。登録業務を分けた登録局(RA)を置くこともある。
- ディジタル証明書
- 公開鍵と持ち主の情報を、認証局が自らの秘密鍵で署名した電子的な身分証明書。有効期限、発行者、シリアル番号などを含む。これにより受け取った公開鍵が本人のものだと確認できる。
- ルート証明書
- 証明書チェーンの頂点にある、認証局が自分自身に発行した自己署名証明書。OSやブラウザにあらかじめ組み込まれ、信頼の起点になる。出所の分からないルート証明書を入れると通信の盗聴や偽サイトを許す。
- CRL(証明書失効リスト)
- 有効期限前に失効させた証明書の一覧。秘密鍵の漏えいや退職などで発行される。件数が増えると取得の負担が大きく、更新間隔の分だけ情報が古くなるという弱点がある。
- OCSP
- 証明書が失効していないかを、1件ずつオンラインで問い合わせて確認する仕組み。CRLを丸ごと取得する必要がなく、より新しい状態を確認できる。応答をサーバ側でまとめて返す方式もある。
- タイムスタンプ
- 時刻認証局(TSA)が、その時刻にその電子データが存在し、以後変更されていないことを証明する仕組み。電子署名が「誰が」を示すのに対し、タイムスタンプは「いつ」を示す。
- 電子署名法
- 一定の要件を満たす電子署名が行われた電磁的記録に、手書きの署名や押印と同様の推定効力を認める法律。本人だけが行える方式であることなどが要件となる。契約の電子化を支える。
- TLS
- 通信路を暗号化し、サーバの正当性を証明書で確認するプロトコル。旧称SSL。公開鍵暗号でセッション鍵を共有し、以後は共通鍵暗号で通信するハイブリッド方式。HTTPに適用したものがHTTPS。
- サーバ証明書の種類(DV・OV・EV)
- DVはドメイン名の管理権のみ確認、OVは組織の実在も確認、EVはさらに厳格な審査を行う。違いは身元確認の厳しさであり、暗号の強度そのものが変わるわけではない。
例題 取引先へ送る見積書に、改ざんされていないことと自社が作成したことを示したい。誰のどの鍵を使うか。
自社(送信者)の秘密鍵で署名する。取引先は自社の公開鍵で検証する。ここで取引先の公開鍵を使うのは暗号化(機密性)の話であり、署名ではない。
例題 ディジタル署名を付けたメールなら、盗み見されても中身は安全といえるか。
いえない。署名は改ざんの検知・本人性・否認防止のための仕組みで、本文は平文のまま送られる。中身も隠したいなら、署名に加えて受信者の公開鍵で暗号化する必要がある。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類1 情報セキュリティ(認証技術・公開鍵基盤)/電子署名法
利用者を確かめる(認証)
パスワード・ワンタイムパスワード・生体認証・パスキーまで、「その人が本人か」を確かめる手段と限界を整理します。
認証とは、システムを使おうとしている相手が名乗ったとおりの本人かどうかを確かめることです。確かめ方は大きく3つの要素に分けられます。本人だけが知っている知識(パスワード、PIN)、本人だけが持っている所持(ICカード、スマートフォン、トークン)、本人自身の特徴である生体(指紋、顔、虹彩、静脈)です。
多要素認証(MFA)は、この3要素のうち異なる種類を2つ以上組み合わせる方式です。二段階認証は、確認の手順を2回に分ける方式で、要素が同じでも成り立ちます。パスワードのあとに秘密の質問を聞くのは、どちらも知識なので二段階認証ではあっても多要素認証ではありません。パスワードとスマートフォンのワンタイムパスワードなら、知識と所持で多要素認証になります。
パスワードは今も主役ですが、弱点も明らかです。短いパスワードは総当たり攻撃で破られ、使い回しは一つの漏えいが全サービスに広がるパスワードリスト攻撃を招きます。文字種を無理に増やすより、十分な長さを確保する方が効果的です。近年は、漏えいの兆候がない限り定期的な変更を一律に強制しない考え方が主流になっています。頻繁な変更はかえって単純で規則的なパスワードを生むためです。覚えきれない分はパスワードマネージャで管理します。
ワンタイムパスワード(OTP)は、一度きりしか使えない使い捨てのパスワードです。時刻を種にする時刻同期方式(タイムスタンプ方式)や、直前の値から次を作る方式などがあり、盗聴された値を後からもう一度使うこと(リプレイ)ができないため、盗み見や盗聴に強くなります。ただし、偽サイトが入力された値をその場で本物のサイトへ中継するリアルタイムフィッシングは防げません。チャレンジレスポンス方式は、サーバが毎回異なるチャレンジ(乱数)を送り、利用者側がパスワードとチャレンジから計算した値だけを返す方式で、パスワードそのものはネットワークを流れません。
生体認証は、忘れず持ち歩く必要もない一方、判定にあいまいさが残ります。本人なのに拒否してしまう割合が本人拒否率(FRR)、他人なのに受け入れてしまう割合が他人受入率(FAR)です。この2つは判定のしきい値でトレードオフの関係にあります。判定を厳しくするとFRRは上がりFARは下がり、判定を緩めるとFRRは下がりFARは上がります。両者が等しくなる点をEER(等誤り率)といい、値が小さいほど精度の高い装置といえます。機密区域の入退室のように安全を優先する場面ではFARを下げる設定にし、その分だけ本人が拒否される不便は受け入れます。
生体情報は漏えいしても取り替えられないという性質があるため、特徴量として保存し、原本の画像を残さない運用が求められます。また指の傷や照明などの環境で結果が変わるため、代替手段を必ず用意します。
そのほかの手段として、自動化された大量アクセスを防ぐために人間かどうかを判定するCAPTCHA、いつもと違う端末・地域・時刻からのログインを検知したときだけ追加の確認を求めるリスクベース認証があります。リスクベース認証は、通常時の利便性を落とさずに不正ログインを抑えられる点が利点です。
一度の認証で複数のシステムを使えるようにするのがシングルサインオン(SSO)です。利用者は覚えるパスワードが減り、管理者は退職時に1か所を止めれば全体を遮断できます。ただし認証情報が破られると被害が一気に広がるため、多要素認証との併用が前提です。実現方式には、組織間で認証情報を受け渡すSAML、権限の委譲を扱うOAuth 2.0、OAuthを土台に認証の機能を加えたOpenID Connectがあります。
パスワードそのものをなくす方向も進んでいます。FIDO2やパスキーは、端末内に秘密鍵を保管し、生体認証や画面ロック解除で秘密鍵の利用を許可して、サーバから届いたチャレンジに署名を返す仕組みです。サーバ側に共有の秘密(パスワード)が保存されないため、漏えいしても悪用できず、偽サイトに署名を渡さない作りになっているためフィッシングにも強くなります。
| 区分 | 名称 | 具体例 | 注意点 |
|---|---|---|---|
| 3要素 | 知識(本人だけが知っている) | パスワード、PIN、秘密の質問 | 盗み見・推測・使い回しに弱い |
| 3要素 | 所持(本人だけが持っている) | ICカード、スマートフォンのアプリ、ハードウェアトークン | 紛失・盗難で他人に使われる恐れ |
| 3要素 | 生体(本人自身の特徴) | 指紋、顔、虹彩、静脈、声紋 | 漏えいしても取り替えられない。FRRとFARの調整が必要 |
| 組合せ | 多要素認証(MFA) | パスワード(知識)+ワンタイムパスワードのアプリ(所持) | 異なる要素を2つ以上。パスワード漏えいだけでは突破されない |
| 組合せ | 二段階認証 | パスワード(知識)+秘密の質問(知識) | 段階は2つでも要素が同じなら多要素認証ではない |
| 指標 | 本人拒否率(FRR) | 本人を誤って拒否する割合 | 判定を厳しくすると上がる(不便になる) |
| 指標 | 他人受入率(FAR) | 他人を誤って受け入れる割合 | 判定を厳しくすると下がる(安全になる) |
- 認証の3要素
- 知識(本人だけが知っていること)、所持(本人だけが持っているもの)、生体(本人自身の特徴)の3つ。どれか一つに頼ると、その一つが破られた時点で突破されるため、異なる要素の組合せが推奨される。
- 多要素認証(MFA)
- 認証の3要素のうち、異なる種類を2つ以上組み合わせる方式。パスワード(知識)とスマートフォンのワンタイムパスワード(所持)の組合せが典型。パスワードが漏えいしても単独では突破されない。
- 二段階認証
- 認証の手順を2回に分ける方式。要素の種類は問わないため、パスワードのあとに秘密の質問を聞く形は二段階認証ではあるが、どちらも知識なので多要素認証ではない。多要素認証の方が強い。
- パスワードリスト攻撃
- どこかで漏えいした利用者IDとパスワードの組を、別のサービスでそのまま試す攻撃。パスワードの使い回しが原因で成立する。長さや複雑さでは防げず、使い回しをやめることと多要素認証が対策になる。
- ワンタイムパスワード(OTP)
- 一度しか使えない使い捨てのパスワード。時刻に基づく方式や、専用アプリ・トークン・SMSで受け取る方式がある。盗聴されても再利用できないため、パスワードの使い回しや盗み見に強い。
- チャレンジレスポンス認証
- サーバが毎回異なる乱数(チャレンジ)を送り、利用者側がパスワードとチャレンジから計算した応答だけを返す方式。パスワードそのものが通信路を流れないため、盗聴による再利用を防げる。
- 本人拒否率(FRR)
- 生体認証で、本人なのに誤って拒否してしまう割合。判定を厳しくすると高くなり、利用者にとっては不便になる。他人受入率(FAR)とはトレードオフの関係にある。
- 他人受入率(FAR)
- 生体認証で、他人なのに誤って本人と認めてしまう割合。安全性に直結する指標で、判定を厳しくすると低くなる。機密区域では、多少の不便を受け入れてもFARを下げる設定にする。
- EER(等誤り率)
- 本人拒否率と他人受入率が等しくなる点の誤り率。装置どうしの精度を比べる目安として使われ、値が小さいほど性能が高い。実際の運用では用途に応じてしきい値をずらして使う。
- CAPTCHA
- ゆがんだ文字や画像の選択などにより、操作しているのが人間か自動プログラムかを判定する仕組み。会員登録や問合せフォームでの大量の自動投稿や、総当たりログインの抑止に使われる。
- リスクベース認証
- 普段と異なる端末・地域・時刻などからのアクセスを危険と判断したときだけ、追加の確認を求める方式。通常時の利便性を保ちながら、なりすましログインを抑えられる。
- シングルサインオン(SSO)
- 一度の認証で複数のシステムを利用できるようにする仕組み。利用者の負担が減り、退職時の停止も1か所で済む。一方で認証が破られたときの影響が大きく、多要素認証との併用が前提となる。
- SAML・OAuth・OpenID Connect
- SAMLは組織間で認証情報を安全に受け渡す規格。OAuth 2.0は他サービスへ権限を委譲する(認可の)規格。OpenID ConnectはOAuth 2.0を土台に本人確認(認証)の機能を加えた規格。
- FIDO2・パスキー
- 端末内の秘密鍵で署名を返すことで本人を確認する、パスワードに依存しない認証方式。サーバに共有の秘密が保存されず、正規サイト以外には署名を返さないため、漏えいにもフィッシングにも強い。
例題 入退室管理の指紋認証で、他人がまぎれ込む事故を減らしたい。判定のしきい値をどう調整し、その結果どちらの指標がどう動くか。
判定を厳しくする。すると他人受入率(FAR)は下がり安全になるが、本人拒否率(FRR)は上がって本人が入れない場面が増える。両者はトレードオフなので、代替の入室手段を用意しておく。
例題 「パスワードを入力したあと、登録済みの秘密の質問に答える」方式は多要素認証か。
多要素認証ではない。パスワードも秘密の質問も知識という同じ要素なので、二段階認証にとどまる。所持(スマートフォンのワンタイムパスワード)や生体を組み合わせて初めて多要素認証になる。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類1 情報セキュリティ(認証技術・利用者認証)
アクセスを制御する
本人と確かめた後に「何をしてよいか」を決める認可の考え方と、権限を最小限に保つ運用の型を身につけます。
認証と認可は必ず区別します。認証(Authentication)は「あなたが誰か」を確かめること、認可(Authorization)は「その人に何を許すか」を決めることです。順番は認証が先で認可が後です。正しくログインできた(認証された)からといって、すべての情報を見てよいわけではありません。人事情報を見られるのは人事部だけ、といった線引きが認可の仕事です。
アクセス制御は、この認可を仕組みとして実現するものです。誰が(主体)、どの情報資産に(客体)、どんな操作を(読取り・書込み・実行・削除)してよいかを定め、記録します。代表的な方式が3つあります。
任意アクセス制御(DAC)は、情報の所有者(作成者)が自分の判断で他人に権限を与えられる方式です。共有フォルダで作成者が公開範囲を決めるような身近な運用ですが、所有者の判断次第なので、組織全体の方針を徹底しにくいという弱点があります。
強制アクセス制御(MAC)は、システム全体の方針(機密ラベルなど)に従って権限が決まり、所有者であっても勝手に変更できない方式です。厳格な機密管理に向きますが、運用は硬く柔軟性に欠けます。
ロールベースアクセス制御(RBAC)は、職務に応じたロール(役割)に権限をまとめ、人はロールに割り当てる方式です。人事異動のときは所属するロールを付け替えるだけで済み、権限の棚卸しもロール単位で行えるため、一般企業で最も広く使われています。
権限を決めるときの原則が、最小権限の原則です。業務の遂行に必要な最小限の権限だけを与え、必要がなくなったら速やかに外します。似た考え方にNeed-to-Know(知る必要性)があり、必要な人だけが必要な情報を知るという情報の与え方の原則です。「念のため広めに」は事故のもとで、権限が広いほど誤操作も内部不正も被害が大きくなります。
職務分掌は、申請する人と承認する人、開発する人と本番環境へ反映する人のように、不正が一人で完結しないよう役割と権限を分けることです。相互牽制が働き、誤りも見つかりやすくなります。
特に注意が必要なのが、システム管理者などの特権IDです。何でもできてしまうため、共用せず個人に紐づける、通常業務では一般IDを使い必要なときだけ昇格する、貸出しと返却を記録する、操作ログを取得して本人以外が点検する、といった管理を行います。
アカウントは発行・変更・削除というライフサイクル全体で管理します。入社時に必要最小限で発行し、異動時には新しい部署の権限を与えると同時に前の部署の権限を必ず外し(権限の残留を防ぐ)、退職時には遅滞なく停止・削除します。加えて、定期的な棚卸しで、使われていないアカウントや不要になった権限を洗い出します。退職者のアカウントが生き残っていることは、典型的な指摘事項です。
利用者・端末・権限の情報を一元管理する基盤がディレクトリサービスです。1か所で登録や停止を行えば各システムに反映でき、シングルサインオンの土台にもなります。
ゼロトラストは、「社内ネットワークだから安全」という前提を捨て、すべてのアクセスを検証するという考え方です。テレワークやクラウド利用で境界があいまいになったことが背景にあります。利用者と端末を毎回確認し、権限は最小限にし、通信は暗号化し、アクセスの記録を継続的に監視します。境界防御(ファイアウォール)を捨てるという意味ではなく、内側も信用しないという前提を足すものです。
| 方式 | 誰が権限を決めるか | 特徴 | 向いている場面 |
|---|---|---|---|
| 任意アクセス制御(DAC) | 情報の所有者(作成者) | 所有者が自分の判断で他人に権限を与えられる。柔軟だが方針の徹底が難しい | 部門内の共有フォルダなど身近な運用 |
| 強制アクセス制御(MAC) | 組織の方針(機密ラベル) | ラベルに従って自動的に決まり、所有者でも変更できない。硬いが強固 | 軍事・政府など厳格な機密管理 |
| ロールベースアクセス制御(RBAC) | ロール(役割)の設計者 | 職務ごとのロールに権限をまとめ、人をロールに割り当てる。異動に強い | 人事異動の多い一般企業。権限の棚卸しがしやすい |
| 属性ベースアクセス制御(ABAC) | 属性の組合せを定めた規則 | 所属・時刻・場所・端末の状態などの属性で動的に判断する | 在宅勤務など状況に応じた細かい制御 |
- 認証と認可
- 認証は名乗った相手が本人かを確かめること、認可は本人と分かった相手に何を許すかを決めること。認証が先、認可が後。ログインできることと、その情報を見てよいことは別である。
- アクセス制御
- 誰が、どの情報資産に、どんな操作をしてよいかを定めて実施すること。読取り・書込み・実行・削除といった操作ごとに設定し、その結果をログに記録して事後に確認できるようにする。
- 任意アクセス制御(DAC)
- 情報の所有者(作成者)が自分の判断で他人に権限を与えられる方式。柔軟で身近だが、所有者の判断に委ねられるため、組織全体の方針を徹底しにくく、権限が広がりやすい。
- 強制アクセス制御(MAC)
- システム全体の方針や機密ラベルに従って権限が決まり、情報の所有者でも変更できない方式。厳格な機密管理に向く一方、運用が硬く、業務の変化への柔軟な対応が難しい。
- ロールベースアクセス制御(RBAC)
- 職務に応じたロールに権限をまとめ、利用者をロールに割り当てる方式。人事異動ではロールを付け替えるだけで済み、権限の棚卸しもロール単位で行えるため、企業で広く使われる。
- 最小権限の原則
- 業務の遂行に必要な最小限の権限だけを与え、不要になったら速やかに外すという原則。権限が広いほど、誤操作による事故も内部不正による被害も大きくなるため、まず絞ることを考える。
- Need-to-Know
- 知る必要のある人だけが、必要な範囲の情報を知るという原則。最小権限の原則が「できること」を絞るのに対し、こちらは「知ってよい情報」を絞る。共有範囲の見直しに使う考え方。
- 職務分掌
- 申請と承認、開発と本番反映のように、不正が一人で完結しないよう役割と権限を分けること。相互牽制が働き、誤りの早期発見にもつながる。少人数の職場では代替の統制を検討する。
- 特権ID
- システム管理者権限など、ほぼ何でもできてしまうID。共用せず個人に紐づける、必要なときだけ使う、貸出しと返却を記録する、操作ログを本人以外が点検する、といった厳重な管理を行う。
- アカウントのライフサイクル
- 発行・変更・削除の一連の流れ。入社時は最小限で発行し、異動時は新しい権限の付与と同時に旧権限を外し、退職時は遅滞なく停止する。定期的な棚卸しで不要なアカウントと権限を洗い出す。
- ディレクトリサービス
- 利用者・端末・権限などの情報を一元的に管理し、各システムから参照できるようにする基盤。1か所での登録や停止が全体に反映でき、シングルサインオンの土台にもなる。
- ゼロトラスト
- 社内ネットワークだから安全という前提を置かず、すべてのアクセスを毎回検証する考え方。利用者と端末の確認、最小権限、通信の暗号化、継続的な監視を組み合わせる。境界防御を捨てる意味ではない。
例題 営業部から経理部へ異動した社員について、アカウント管理で必ず行うべきことは何か。
経理部の業務に必要な権限を与えると同時に、営業部で使っていた権限を必ず外すこと。付与だけ行って旧権限を残すと権限が積み上がり、最小権限の原則に反する状態になる。
例題 「ログインできたのだから、この共有フォルダの中身も見てよいはずだ」という主張のどこが誤りか。
認証(本人と確かめること)と認可(何を許すか)を混同している。ログインの成功は本人であることを示すだけで、個々の資産を見てよいかは別に定められた認可の問題である。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類4 情報セキュリティ対策(アクセス管理)/JIS Q 27002 アクセス制御
情報セキュリティ管理
情報資産を洗い出して分類する
何を守るのかを決めないと守れない。情報資産の洗い出し、台帳への記録、分類とラベリング、そして最後の廃棄までを押さえます。
情報セキュリティの出発点は「守るべきものは何か」をはっきりさせることです。ここで守る対象を情報資産と呼びます。情報資産は紙やデータだけではありません。顧客名簿や設計図などのデータ、契約書や申込書などの書類、それを扱うパソコン・サーバ・USBメモリ・スマートフォンなどの機器、業務アプリケーションやOSなどのソフトウェア、そして担当者しか知らない手順やノウハウといった人が持つ知識、さらに会社の信用やブランドといった無形資産まで含みます。守る範囲を狭く考えると、そこから漏れたところが弱点になります。
洗い出した情報資産は情報資産台帳(情報資産管理台帳)にまとめます。台帳に書くのは、資産名、資産の管理責任者(オーナー)、保管場所、媒体の種類(紙・電子・機器)、機密度、重要度、そして数量や利用者の範囲です。台帳がないと「誰の持ち物か分からない情報」が生まれ、事故が起きても被害範囲を特定できません。台帳は作って終わりではなく、定期的な棚卸しで実物と突き合わせ、増えた資産・廃棄した資産を反映して最新に保ちます。
台帳ができたら情報を分類します。よく使われるのは、外部に出ると重大な影響が出る「機密(極秘)」、社内に限って共有する「社外秘」、誰が見てもよい「公開」といった段階です。分類の基準は機密性だけでなく、失われたときの影響(完全性・可用性)も見て決めます。分類したら、その区分がひと目で分かるようにラベリングします。紙なら表紙や欄外への表示、電子ファイルならファイル名やヘッダ、フォルダ単位の表示です。ラベルがあるから、扱う人は「これはメール添付してよいのか」を判断できます。
資産には役割を決めます。管理責任者(情報資産のオーナー)は、その資産の分類を決め、誰にどこまでのアクセスを許すかを承認し、定期的に見直す責任を負います。利用者は、決められた分類とルールの範囲内で使い、持ち出しや複製は承認を得て行い、異常に気付いたら報告します。「管理責任者は分類と承認、利用者は遵守と報告」という分担が基本です。
情報には一生があります。作成(取得)、利用、保管、移送(持出し・送付)、廃棄というライフサイクルの各段階に、それぞれ守るべきことがあります。作成時は分類を決める、利用時はアクセス権の範囲で使う、保管時は施錠保管や暗号化、移送時は封緘・書留・暗号化・受渡し記録、そして最後が廃棄です。
廃棄はもっとも忘れられやすく、もっとも事故が起きやすい段階です。紙はシュレッダーで細断するか溶解処理にします。電子データは、ごみ箱を空にしただけ、クイックフォーマットしただけでは復元できてしまうので、データ消去ソフトによる上書き消去や暗号化消去を行います。ハードディスクやSSDを処分するときは物理破壊(穿孔・破砕)が確実です。処分を外部業者に委託するときは、作業の立会いか、破壊証明書・データ消去証明書の受領によって、確かに消去されたことを記録として残します。
| 区分 | 項目・区分 | 内容の例 |
|---|---|---|
| 台帳の項目 | 資産名 | 顧客名簿、見積書ファイル、営業用ノートPC |
| 台帳の項目 | 管理責任者 | 営業部長(分類の決定とアクセス権の承認を行う) |
| 台帳の項目 | 保管場所 | 施錠キャビネット、ファイルサーバの共有フォルダ |
| 台帳の項目 | 媒体 | 紙/電子ファイル/可搬媒体/機器 |
| 台帳の項目 | 機密度 | 機密・社外秘・公開のどれに当たるか |
| 台帳の項目 | 重要度 | 失われたときの業務への影響の大きさ |
| 分類の例 | 機密(極秘) | 漏えいすると重大な損害。限られた担当者だけが閲覧 |
| 分類の例 | 社外秘 | 社内では共有してよいが社外に出さない |
| 分類の例 | 公開 | 誰が見てもよい。公開済みの製品情報など |
| 廃棄方法 | 紙 | シュレッダーで細断、または溶解処理 |
| 廃棄方法 | 電子データ | 消去ソフトによる上書き消去、暗号化消去 |
| 廃棄方法 | 記憶媒体 | 穿孔・破砕などの物理破壊 |
| 廃棄方法 | 委託時 | 作業への立会い、または破壊・データ消去証明書の受領 |
- 情報資産
- 組織にとって価値があり守るべき対象。データや書類だけでなく、それを扱う機器・ソフトウェア、担当者の知識やノウハウ、企業の信用やブランドといった無形のものも含む。
- 情報資産台帳
- 洗い出した情報資産を一覧にした管理簿。資産名・管理責任者・保管場所・媒体・機密度・重要度などを記録し、定期的な棚卸しで最新の状態に保つ。
- 管理責任者(資産のオーナー)
- その情報資産の分類を決め、アクセス権を承認し、定期的に見直す責任を持つ人。利用者は決められたルールの範囲内で使い、異常があれば報告する立場。
- ラベリング
- 情報の分類区分を、紙なら表示、電子ならファイル名やヘッダなどで見て分かるようにすること。扱う人が取扱いを判断できるようにするために行う。
- 情報のライフサイクル
- 作成・利用・保管・移送・廃棄という情報の一生。段階ごとに必要な管理策が異なり、とくに移送と廃棄で事故が起きやすい。
- データ消去証明書
- 記憶媒体のデータ消去や物理破壊を委託したときに、作業が確かに行われたことを示す書面。立会いとあわせて、廃棄の証拠を残す手段になる。
例題 退役するノートPCを産業廃棄物として業者に引き渡す前に、利用部門としてやるべきことは何か。
内蔵ストレージのデータを消去ソフトで上書き消去するか物理破壊し、情報資産台帳から当該資産を抹消する。委託する場合は立会いか消去証明書の受領で証拠を残す。ごみ箱を空にしただけ、フォーマットしただけでは復元される可能性がある。
例題 情報資産の棚卸しを年1回行う目的は何か。
台帳の記載と実物のずれをなくすため。新しく増えた資産が台帳に載っていなければ管理策が当たらず、逆に廃棄済みの資産が残っていれば所在不明の資産を追いかけることになる。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類2 情報セキュリティ管理(情報資産の調査・分類、情報資産台帳)/JIS Q 27000 用語
リスクアセスメント
リスク特定→リスク分析→リスク評価という順序と、回避・移転・低減・受容という4つの対応。試験で最も問われる骨格です。
リスクマネジメントは、組織の目的の達成を邪魔しうる不確かさを、洗い出して、評価して、対応して、見直し続ける一連の活動です。大きな流れは、まず適用範囲や前提を決め(状況の確定)、次にリスクアセスメントを行い、その結果に基づいてリスク対応を決め、実施し、監視とレビューで見直す、というサイクルになります。関係者への説明や意見交換であるリスクコミュニケーションは、この全体を通じて行います。
この中でリスクアセスメントは、リスク特定→リスク分析→リスク評価の3つで構成されます。この順序は繰り返し問われるので確実に覚えてください。リスク特定は、どんなリスクがあるかを見つけて書き出す段階です。情報資産・脅威・脆弱性の組合せで洗い出します。リスク分析は、見つけたリスクの起こりやすさ(発生可能性)と、起きたときの影響の大きさを見積もり、リスクの大きさ(リスクレベル)を求める段階です。リスク評価は、分析で求めた大きさをあらかじめ決めておいたリスク基準と照らして、対応が必要か、どれを優先するかを決める段階です。「見つける→測る→比べる」と覚えると順序を間違えません。
比べるための物差しをリスク基準といいます。中でも「ここまでなら受け入れてよい」という線がリスク受容基準です。この基準は組織が自分で決めるもので、経営層が承認します。基準がないと、分析して数字が出ても対応するかどうかを判断できません。
リスク分析のやり方には定性的評価と定量的評価があります。定性的評価は、発生可能性と影響度を「大・中・小」や3段階・5段階の点数で表し、リスクマトリックス(発生可能性を縦軸、影響度を横軸に取った表)で大きさを決めます。手早くでき、金額で表しにくいリスク(信用の低下など)も扱えるのが利点です。定量的評価は、被害を金額で見積もります。代表的な考え方が年間予想損失額です。
1回事故が起きたときの損失額を単一予想損失額(SLE)、その事故が1年間に起きると見込まれる回数を年間発生率(ARO)といい、年間予想損失額(ALE)はALE=SLE×AROで求めます。たとえば1回で500万円の損失が出る事故が2年に1回(ARO=0.5)起きるなら、ALEは500万円×0.5=250万円です。ALEは対策の費用対効果を判断するのに使えます。対策に年150万円かかり、それによってALEが250万円から50万円に下がるなら、削減額200万円に対して費用150万円なので、金額の面では合理的だと言えます。
評価の結果を受けて行うのがリスク対応です。よく使われる4分類は、回避・移転(共有)・低減(軽減)・受容(保有)です。回避はリスクの原因となる活動そのものをやめることで、たとえば採算の見込みが薄いうえに個人情報を大量に扱う事業から撤退する、危険なサービスの提供を中止する、といった対応です。移転(共有)は、リスクによる損失を他者と分け合うことで、保険に加入する、業務を専門の外部事業者に委託して契約で責任を分担する、といった対応です。低減(軽減)は、対策を打って発生確率を下げたり影響を小さくしたりすることで、ウイルス対策ソフトの導入、暗号化、バックアップ取得、教育などが当たります。受容(保有)は、リスクが受容基準の範囲内で影響も小さいため、あえて対策を取らずそのまま受け入れることです。なお、対策を打っても残るリスクを残留リスクといい、これを受け入れるかどうかは経営層が承認します。「保険=移転」「撤退=回避」「対策=低減」「そのまま=受容」という対応づけが頻出です。
リスク保有(受容)を選ぶのは「面倒だから放置する」ことではありません。対策費用が想定損失を上回る、影響が受容基準の範囲内である、といった根拠を示し、責任者が判断して記録に残すのが正しい保有です。また、リスクの大きさや対応方針は関係者と共有し、意見を交換します。これがリスクコミュニケーションで、経営層・現場・取引先・顧客との認識のずれをなくす役割を持ちます。
| 区分 | 名称 | 内容・具体例 |
|---|---|---|
| 手順1 | リスク特定 | 情報資産・脅威・脆弱性からリスクを洗い出して書き出す |
| 手順2 | リスク分析 | 発生可能性と影響度を見積もり、リスクの大きさを求める |
| 手順3 | リスク評価 | 求めた大きさをリスク基準と比べ、対応の要否と優先順位を決める |
| 手順4 | リスク対応 | 評価結果に基づき、回避・移転・低減・受容から選んで実施する |
| 対応 | 回避 | リスクの原因となる活動をやめる。例)その事業から撤退する、危険なサービスを中止する |
| 対応 | 移転(共有) | 損失を他者と分け合う。例)保険に加入する、専門業者に委託して契約で責任を分担する |
| 対応 | 低減(軽減) | 発生確率や影響を小さくする。例)ウイルス対策ソフト導入、暗号化、バックアップ、教育 |
| 対応 | 受容(保有) | 影響が小さく基準内なので対策せず受け入れる。根拠を示して責任者が承認する |
| 用語 | 残留リスク | 対応後に残るリスク。受け入れるかどうかを経営層が承認する |
| 用語 | ALE | 年間予想損失額。ALE=SLE(1回の損失額)×ARO(年間発生率) |
- リスクアセスメント
- リスク特定・リスク分析・リスク評価の3つからなる一連の活動。どんなリスクがあるかを洗い出し、大きさを見積もり、リスク基準と比べて対応の要否と優先順位を決める。
- リスク特定
- アセスメントの最初の段階。情報資産・脅威・脆弱性の組合せから、どのようなリスクが存在するかを発見し、認識し、記述する。ここでは大きさの判断はしない。
- リスク分析
- 特定したリスクについて、発生可能性と起きたときの影響の大きさを見積もり、リスクレベルを決める段階。定性的評価と定量的評価がある。
- リスク評価
- 分析で求めたリスクレベルをリスク基準と比較し、対応が必要かどうか、どれから対応するかを決める段階。アセスメントの最後に位置する。
- リスク受容基準
- 組織が「ここまでの大きさなら受け入れてよい」と定めた線。経営層が承認する。この基準がなければ評価の判断ができない。
- 年間予想損失額(ALE)
- 1年間に見込まれる損失額。単一予想損失額(SLE)に年間発生率(ARO)を掛けて求める。ALE=SLE×ARO。対策費用と比較して費用対効果を判断できる。
- リスクマトリックス
- 発生可能性と影響度をそれぞれ段階で表し、交差する位置でリスクの大きさを判定する表。定性的評価でよく用いられる。
- 残留リスク
- リスク対応を実施したあとも残るリスク。ゼロにはできないため、残った分を受け入れるかどうかを責任者(経営層)が判断し承認する。
- リスクコミュニケーション
- リスクとその対応について、経営層・従業員・取引先・顧客などの関係者と情報を共有し意見を交換する活動。認識のずれを防ぐ。
例題 1回発生すると800万円の損失が出る事故があり、4年に1回の頻度で発生すると見込まれる。ALEはいくらか。また年間180万円の対策で発生頻度を10年に1回にできるとき、その対策は金額面で見合うか。
ARO=1/4=0.25なので、ALE=800万円×0.25=200万円。対策後はARO=0.1となりALE=800万円×0.1=80万円。削減額は200-80=120万円で、対策費用180万円を下回るため、金額の面だけで見ると見合わない。
例題 「サーバ室が浸水するリスクがある」と書き出した段階は、リスクアセスメントのどこに当たるか。
リスク特定。大きさの見積りはリスク分析、基準と比べて対応の要否を決めるのがリスク評価。特定→分析→評価の順序を取り違えないこと。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類2 情報セキュリティ管理(リスクマネジメント、リスクアセスメント、リスク対応)/JIS Q 27000 用語/JIS Q 31000
ISMSと規格
ISMSの考え方と、JIS Q 27001と27002の違い、PDCA、適合性評価制度、プライバシーマークまでを整理します。
ISMS(情報セキュリティマネジメントシステム)は、情報セキュリティを個々の技術的な対策だけに任せず、組織の仕組みとして継続的に管理する枠組みです。目的は、情報の機密性・完全性・可用性を維持しながら、リスクを組織が受け入れられる水準に保つことです。特定の製品を入れれば実現するものではなく、方針を決め、リスクアセスメントを行い、管理策を選び、実施し、監視し、改善するという一連の活動全体を指します。
規格の役割分担をはっきりさせましょう。JIS Q 27001は、ISMSに対する要求事項を定めた規格です。「組織はこうしなければならない」という形で書かれ、認証の基準になります。一方JIS Q 27002は、情報セキュリティ管理策の実践のための規範(ガイドライン)です。個々の管理策をどう実装すればよいかの手引きであり、要求事項ではありません。つまり「27001=要求事項・認証の対象、27002=実践の手引き」です。この2つを入れ替えた誤りの選択肢が頻繁に出るので、番号と役割をセットで覚えてください。なお、用語や概要を定めているのがJIS Q 27000です。
組織のISMSが27001の要求事項を満たしているかを、第三者である認証機関が審査して認証するのがISMS適合性評価制度です。日本ではISMS-AC(情報マネジメントシステム認定センター)が認証機関を認定し、認定された認証機関が組織を審査します。認証は取れば終わりではなく、定期的な維持審査と数年ごとの更新審査を受け続けます。
ISMSの運用はPDCAサイクルで回します。Plan(計画)で、適用範囲を決め、情報セキュリティ方針を定め、リスクアセスメントを行い、管理策を選定します。Do(実行)で、管理策を導入し、教育を行い、日々運用します。Check(点検)で、監視・測定を行い、内部監査を実施し、マネジメントレビューで経営層が有効性を評価します。Act(改善)で、不適合の是正処置を行い、仕組みそのものを見直します。この繰り返しが継続的改善です。
Planの成果物として重要なのが適用宣言書です。適用宣言書には、選択した管理策とその選択理由、実施状況、そして採用しなかった管理策についてはその除外理由を記載します。「なぜこの管理策を選び、なぜこれは要らないと判断したか」を説明する文書だと理解してください。もう一つの中核が情報セキュリティ方針で、組織としての基本的な考え方と経営層のコミットメントを示し、全員に周知します。
点検の要が内部監査とマネジメントレビューです。内部監査は、決めたとおりに運用されているか、有効に機能しているかを組織自身が確認する活動で、客観性を保つため監査人は自分の担当業務を監査しません。マネジメントレビューは、監査結果や指標、インシデントの状況などを踏まえ、経営層がISMSの適切性・妥当性・有効性を評価し、改善や資源配分を指示する場です。
個人情報を扱う仕組みには別の規格があります。JIS Q 15001は個人情報保護マネジメントシステム(PMS)の要求事項を定めた規格で、これに適合していることを審査して付与されるのがプライバシーマーク(Pマーク)です。「27001=ISMS認証、15001=プライバシーマーク」という対応で覚えます。ISO/IEC 27017はクラウドサービスの情報セキュリティ管理策に関する規範、ISO/IEC 27701はプライバシー情報マネジメント(PIMS)に関する規格です。制御システム向けのマネジメントシステムはCSMS(サイバーセキュリティマネジメントシステム)と呼ばれ、その適合性評価制度もあります。また、企業の情報セキュリティ対策の水準を第三者が評価して等級で示す情報セキュリティ格付という仕組みもあります。
| 区分 | 名称 | 内容 |
|---|---|---|
| 規格 | JIS Q 27000 | ISMSの用語と概要を定める |
| 規格 | JIS Q 27001 | ISMSの要求事項。認証の基準になる |
| 規格 | JIS Q 27002 | 情報セキュリティ管理策の実践のための規範(手引き) |
| 規格 | JIS Q 15001 | 個人情報保護マネジメントシステム(PMS)の要求事項 |
| 規格 | ISO/IEC 27017 | クラウドサービスの情報セキュリティ管理策の規範 |
| 規格 | ISO/IEC 27701 | プライバシー情報マネジメントシステム(PIMS)の規格 |
| 認証 | ISMS適合性評価制度 | JIS Q 27001への適合を第三者の認証機関が審査し認証する |
| 認証 | プライバシーマーク | JIS Q 15001への適合を審査して付与される個人情報保護の認証 |
| PDCA | Plan | 適用範囲の決定、方針の策定、リスクアセスメント、管理策の選定と適用宣言書 |
| PDCA | Do | 管理策の導入と運用、教育・訓練の実施 |
| PDCA | Check | 監視・測定、内部監査、マネジメントレビュー |
| PDCA | Act | 不適合の是正処置、仕組みの見直しによる継続的改善 |
- ISMS
- 情報セキュリティマネジメントシステム。情報の機密性・完全性・可用性を維持し、リスクを受容可能な水準に保つための組織的な仕組み。技術対策だけでなく方針・運用・改善までを含む。
- JIS Q 27001
- ISMSの要求事項を定めた規格。認証の基準となり、「〜しなければならない」という形で組織がすべきことを規定する。
- JIS Q 27002
- 情報セキュリティ管理策の実践のための規範。個々の管理策をどう実装するかの手引きであり、認証の要求事項ではない。
- 適用宣言書
- 選択した管理策とその選択理由、実施状況、および採用しなかった管理策の除外理由を記載した文書。管理策の取捨選択の根拠を示す。
- ISMS適合性評価制度
- 組織のISMSがJIS Q 27001の要求事項に適合しているかを第三者の認証機関が審査し認証する制度。認定機関がその認証機関を認定する。
- マネジメントレビュー
- 内部監査結果や測定値、インシデント状況などを踏まえ、経営層がISMSの適切性・妥当性・有効性を評価し、改善や資源配分を指示する活動。
- JIS Q 15001
- 個人情報保護マネジメントシステム(PMS)の要求事項を定めた規格。この規格への適合を審査して付与されるのがプライバシーマーク。
- ISO/IEC 27017
- クラウドサービスに関する情報セキュリティ管理策の実践の規範。クラウド事業者と利用者それぞれの立場での管理策の指針を示す。
- ISO/IEC 27701
- プライバシー情報マネジメントシステム(PIMS)に関する規格。ISMSの枠組みを拡張し、個人情報の取扱いに関する要求事項と手引を示す。
例題 「当社はJIS Q 27002の認証を取得しました」という表現はなぜ誤りか。
27002は管理策の実践のための規範(手引き)であり、認証の基準ではないため。認証の基準になるのは要求事項を定めたJIS Q 27001。
例題 適用宣言書に、採用しなかった管理策について何を書くか。
除外した理由。適用宣言書には、選択した管理策とその選択理由・実施状況に加え、除外した管理策の理由を記載し、判断の根拠を説明できるようにする。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類2 情報セキュリティ管理(ISMS、情報セキュリティマネジメント)/JIS Q 27000/JIS Q 27001/JIS Q 27002/JIS Q 15001/ISO/IEC 27017/ISO/IEC 27701
規程と体制をつくる
情報セキュリティポリシの3階層と、それぞれに何を書くか。CISOや委員会といった体制、周知・例外承認・見直しの手続まで。
決めごとがなければ、現場は判断できません。組織のルールを文書として整えたものが情報セキュリティポリシです。一般に3階層で構成されます。上から順に、基本方針(情報セキュリティポリシの狭義の意味で使われることもあります)、対策基準、実施手順です。上位ほど抽象的で変わりにくく、下位ほど具体的で頻繁に更新されます。
基本方針には、組織として情報セキュリティに取り組む目的、適用範囲、経営陣の責任とコミットメント、遵守の義務と違反時の措置といった、組織の姿勢を書きます。経営層が承認し、全従業員はもちろん、必要に応じて外部にも公開します。中身に具体的な製品名や設定値は書きません。
対策基準には、基本方針を実現するために守るべき事項を分野ごとに書きます。たとえばアクセス制御、パスワードの要件、可搬媒体の持出し、外部委託先の管理、事故発生時の報告といったテーマごとに、何をしなければならないかを定めます。「何をするか(What)」のレベルです。
実施手順には、対策基準を実際にどう行うかを具体的に書きます。手順書・マニュアル・チェックリストの類で、操作の画面や設定値、担当者、記録の残し方まで含みます。「どうやるか(How)」のレベルで、システムの変更に応じて頻繁に改訂されます。試験では、この3階層の順序と、どの内容がどの階層に当たるかがよく問われます。
ポリシは経営の問題です。経営陣は方針を承認し、必要な人・予算・時間を割り当て、自ら遵守する姿勢を示します。これがコミットメントです。実務の責任者として置かれるのがCISO(最高情報セキュリティ責任者)で、組織全体の情報セキュリティ戦略と施策を統括し、経営層に報告します。部門横断で方針・規程の審議や重要事案の判断を行う場が情報セキュリティ委員会です。あわせて、情報資産の管理責任者、システム管理者、一般の利用者など、役割と責任を割り当てて文書化します。誰の仕事か決まっていない作業は、実際には誰もやりません。
作った規程は、周知して初めて効きます。入社時教育、定期的な研修、eラーニング、標的型攻撃メールの訓練などを通じて、対象者に応じた内容で継続的に伝えます。理解度の確認や遵守の誓約を取る方法もあります。周知していないルール違反を一方的に責めることはできません。
現場では、規程どおりにできない事情が出てきます。そのときに必要なのが例外承認の手続です。勝手に破るのでも我慢するのでもなく、申請書に理由・期間・代替の管理策を書いて所定の責任者の承認を受け、記録に残し、期限が来たら見直します。例外を無記録で許すと規程は形骸化します。また規程自体も、法改正、新しい技術やサービスの導入、組織変更、インシデントの発生、内部監査の指摘などを機に、定期的に見直します。
経営層向けの指針としては、経済産業省とIPAが公表するサイバーセキュリティ経営ガイドラインがあります。経営者が認識すべき3原則と、経営者がCISO等に指示すべき重要10項目で構成され、セキュリティを投資として捉え、自社だけでなく取引先を含めた対策や、有事に備えた体制整備を求めています。
| 区分 | 名称 | 書く内容・役割 |
|---|---|---|
| 階層1 | 基本方針 | 取組みの目的、適用範囲、経営陣の責任とコミットメント、遵守義務と違反時の措置 |
| 階層2 | 対策基準 | 分野別に守るべき事項。アクセス制御、パスワード要件、媒体の持出し、委託先管理、報告義務など |
| 階層3 | 実施手順 | 具体的な手順書・マニュアル・チェックリスト。操作方法、設定値、担当者、記録の残し方 |
| 性質 | 上位ほど | 抽象的で変わりにくい。経営層が承認する |
| 性質 | 下位ほど | 具体的で改訂が頻繁。システム変更のたびに更新する |
| 体制 | 経営層 | 方針の承認、資源(人・予算)の割当て、自ら遵守する姿勢を示すコミットメント |
| 体制 | CISO | 組織全体の情報セキュリティ戦略と施策を統括し、経営層に報告する |
| 体制 | 情報セキュリティ委員会 | 部門横断で方針・規程を審議し、重要事案を判断する |
| 体制 | 利用者 | 規程を遵守し、例外が必要なときは申請して承認を得る。異常は速やかに報告する |
| 手続 | 例外承認 | 理由・期間・代替の管理策を書いて申請し、責任者の承認と記録を残して期限で見直す |
| 指針 | サイバーセキュリティ経営ガイドライン | 経営者が認識すべき3原則と、CISO等に指示すべき重要10項目 |
- 情報セキュリティポリシ
- 組織の情報セキュリティに関する規程の体系。一般に基本方針・対策基準・実施手順の3階層で構成し、上位ほど抽象的、下位ほど具体的になる。
- 基本方針
- ポリシの最上位。取組みの目的、適用範囲、経営陣の責任とコミットメント、遵守義務などを示す。経営層が承認し、外部に公開することもある。
- 対策基準
- ポリシの中間層。基本方針を実現するために守るべき事項を、アクセス制御や媒体の持出しなど分野ごとに定める。「何をするか」のレベル。
- 実施手順
- ポリシの最下層。対策基準を実行するための具体的な手順書・マニュアル・チェックリスト。「どうやるか」のレベルで、頻繁に改訂される。
- CISO
- 最高情報セキュリティ責任者。組織全体の情報セキュリティ戦略と施策を統括し、経営層に報告する役割を担う責任者。
- 情報セキュリティ委員会
- 部門横断で情報セキュリティの方針・規程の審議や重要事案の判断を行う組織。経営層や各部門の責任者で構成されることが多い。
- 例外承認
- 規程どおりに実施できない場合に、理由・期間・代替の管理策を明示して所定の責任者の承認を受け、記録に残す手続。期限が来たら見直す。
- サイバーセキュリティ経営ガイドライン
- 経済産業省とIPAが公表する経営者向けの指針。経営者が認識すべき3原則と、経営者がCISO等に指示すべき重要10項目からなる。
例題 「業務で利用するパスワードは英大文字・小文字・数字・記号を含む12文字以上とする」という規定は、ポリシの3階層のどれに当たるか。
対策基準。分野ごとに守るべき事項を定めるのが対策基準で、実際にどの画面でどう設定するかまで書いたものが実施手順、組織の姿勢を示すのが基本方針。
例題 取引先の指定システムが規程で禁止しているファイル共有サービスの利用を求めてきた。担当者はどうすべきか。
独断で使わず、例外承認の手続を取る。利用の理由・対象データ・期間・代替の管理策(暗号化、アクセス権限の限定など)を示して責任者の承認を受け、記録に残して期限が来たら見直す。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類2 情報セキュリティ管理(情報セキュリティポリシ、組織における体制)/サイバーセキュリティ経営ガイドライン(経済産業省・IPA)
事業を止めない備え
BCPとBCM、RTO・RPO・RLO、BIA、そしてバックアップの方式と3-2-1ルール。止まっても戻せる体制を作ります。
災害、大規模なシステム障害、ランサムウェア感染。どれだけ対策しても、事業が止まる事態は起こりえます。そこで必要になるのが事業継続の備えです。BCP(事業継続計画)は、そうした事態が起きたときに、重要な業務をどう継続し、どう復旧させるかを定めた計画そのものです。これに対しBCM(事業継続マネジメント)は、BCPを策定し、教育・訓練を行い、実施状況を点検して見直すという、継続的な運用の仕組み全体を指します。「BCPは計画(文書)、BCMはその計画を作って回し続ける管理活動」という関係です。
計画を作る前提として行うのが事業影響度分析(BIA)です。どの業務が止まると、いつまでに、どれくらいの損害が出るのかを分析し、優先して復旧すべき重要業務と、その業務が依存している資源(システム、人、場所、取引先)を洗い出します。すべてを同時に復旧することはできないので、優先順位を先に決めておくわけです。
復旧の目標は3つの指標で表します。RTO(目標復旧時間)は、障害発生から復旧までにかけてよい時間の目標です。「4時間以内に業務を再開する」という形で表します。RPO(目標復旧時点)は、どの時点のデータまで戻せればよいかという目標で、言い換えるとどれだけのデータ損失を許容するかです。「直近24時間以内のデータまで戻せればよい」と決めたなら、バックアップは少なくとも1日1回必要になります。RLO(目標復旧レベル)は、復旧した時点でどの水準まで業務を回復させるかの目標で、「まず受注業務だけを平常時の50%の処理能力で再開する」といった形です。RTOは時間、RPOは時点(データの鮮度)、RLOは水準。ここは入れ替えた誤りの選択肢が定番なので、しっかり区別してください。
戻すための土台がバックアップです。方式は3つあります。フルバックアップは対象データをすべて取得する方式で、取得に時間と容量を要しますが、復元はその1本だけで済みます。差分バックアップは、直前のフルバックアップ以降に変更されたデータを毎回すべて取得する方式で、日が経つほど1回の取得量は増えますが、復元にはフルバックアップと最新の差分1本があれば足ります。増分バックアップは、前回のバックアップ(フルでも増分でも)以降に変更された分だけを取得する方式で、取得は最も速く容量も小さい代わりに、復元にはフルバックアップとそれ以降のすべての増分が必要になります。「差分は最新の1本だけ、増分は全部いる」と覚えます。増分は媒体が1本でも壊れていると、それ以降を復元できません。
保管の考え方としてよく挙げられるのが3-2-1ルールです。データは原本を含めて3つ持つ、2種類の異なる媒体に保存する、そのうち1つは別の場所(オフサイト)に置く、という指針です。同じ建物の中に3世代置いていても、火災や水害では全部失われます。別の場所に1つ置くのはそのためです。
ランサムウェアへの備えとしては、これに加えてオフライン保管が重要です。ランサムウェアはネットワークでつながっている共有フォルダやNAS、場合によってはクラウドの同期先まで暗号化します。常時接続されているバックアップは一緒にやられます。そこで、取得後は接続を切って保管する(テープや外付け媒体を取り外す)、書き換えできない設定にする、といった対策を取ります。さらに、バックアップから本当に復元できるかを定期的に復元テストで確認します。取れているつもりで壊れていた、という事故は珍しくありません。
拠点が使えなくなる事態には代替拠点を用意します。あらかじめ機器を用意して短時間で切り替えられるホットサイト、機器はあるがデータ復元などの準備が必要なウォームサイト、場所だけ確保しておくコールドサイトがあり、上に行くほど早く復旧できる代わりに費用がかかります。RTOに見合ったものを選びます。そして、計画は訓練して初めて使えます。安否確認、代替手段での業務、システムの切替えなどを実際にやってみて、うまくいかなかった点を計画に反映する。この訓練と見直しの繰り返しがBCMの中身です。
| 区分 | 名称 | 内容 |
|---|---|---|
| 計画 | BCP | 重要業務の継続と復旧の手順を定めた計画そのもの(文書) |
| 計画 | BCM | BCPを策定し教育・訓練・点検・見直しを続ける管理活動の全体 |
| 計画 | BIA | 業務停止の影響を分析し、優先復旧する業務と依存資源を洗い出す |
| 指標 | RTO | 目標復旧時間。いつまでに復旧させるか(例:4時間以内) |
| 指標 | RPO | 目標復旧時点。どの時点のデータまで戻すか(例:24時間前まで) |
| 指標 | RLO | 目標復旧レベル。どの水準まで回復させるか(例:平常時の50%) |
| バックアップ | フル | 全データを取得。取得は遅く容量大。復元はフル1本のみ |
| バックアップ | 差分 | 前回フル以降の変更分を毎回全部取得。復元はフル+最新の差分1本 |
| バックアップ | 増分 | 前回バックアップ以降の変更分だけ取得。復元はフル+以降すべての増分 |
| 保管 | 3-2-1ルール | 原本を含め3つ、2種類の媒体、1つは別の場所(オフサイト) |
| 保管 | オフライン保管 | 取得後は接続を切って保管する。ランサムウェアによる暗号化を防ぐ |
| 拠点 | ホット/ウォーム/コールド | 代替拠点。上ほど復旧が早く費用も高い。RTOに見合うものを選ぶ |
- BCP(事業継続計画)
- 災害や大規模障害が発生したときに、重要な業務をどう継続し復旧させるかを定めた計画そのもの。優先する業務、復旧目標、代替手段、体制などを記載する。
- BCM(事業継続マネジメント)
- BCPを策定し、教育・訓練を行い、点検して見直すという継続的な管理活動の全体。BCPという文書を作って回し続ける仕組みを指す。
- BIA(事業影響度分析)
- 業務が停止したときの影響の大きさと時間的な広がりを分析し、優先して復旧すべき重要業務とその依存資源を明らかにする活動。BCP策定の前提になる。
- RTO(目標復旧時間)
- 障害発生から業務やシステムを復旧させるまでの目標時間。「4時間以内に再開する」のように時間で表す。
- RPO(目標復旧時点)
- どの時点のデータまで復旧させるかの目標。許容できるデータ損失の範囲を示し、必要なバックアップの取得間隔を決める根拠になる。
- RLO(目標復旧レベル)
- 復旧した時点で業務をどの水準まで回復させるかの目標。「平常時の50%の処理能力で再開する」のように操業度で表す。
- 差分バックアップ
- 直前のフルバックアップ以降に変更された分をすべて取得する方式。復元にはフルバックアップと最新の差分1本があればよい。
- 増分バックアップ
- 前回のバックアップ以降に変更された分だけを取得する方式。取得は速いが、復元にはフルバックアップとそれ以降のすべての増分が必要。
- 3-2-1ルール
- データは原本を含めて3つ持ち、2種類の異なる媒体に保存し、そのうち1つは別の場所に保管するというバックアップの指針。
例題 日曜にフルバックアップ、月〜土は増分バックアップを取得している。木曜の業務終了後に障害が発生した場合、復元に必要な媒体はどれか。
日曜のフルバックアップと、月・火・水・木の4本の増分バックアップ、合計5本。増分は前回のバックアップ以降の変更分しか持たないため、間の1本でも欠けると復元できない。これが差分方式なら、日曜のフルと木曜の差分の2本で済む。
例題 RPOを1時間、RTOを8時間と定めた。この意味は何か。
障害が起きても直近1時間より前のデータは失わない(そのためバックアップは1時間おき以上の頻度で取得する必要がある)、かつ8時間以内に業務を復旧させる、という目標。RPOはデータの鮮度、RTOは復旧までの時間を表す。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類2 情報セキュリティ管理(事業継続計画、事業継続管理、バックアップ)
インシデント対応と組織
インシデントが起きたら
おかしいと気づいた瞬間から、何を、どの順でやるのか。そして絶対にやってはいけないことが分かるようになります。
情報セキュリティインシデントとは、望ましくない、または予期しない情報セキュリティ事象のうち、事業運営を危うくし、情報セキュリティを脅かす可能性が高いものをいいます(JIS Q 27000)。「事象(イベント)」はログに残ったアラートや不審な通信など、まだ被害かどうか分からない出来事のこと。それを調べて「これはまずい」と判断されたものがインシデントです。マルウェア感染、ランサムウェアによる暗号化、不正アクセス、Webサイトの改ざん、メールの誤送信、USBメモリやノートPCの紛失・盗難、内部不正による情報の持ち出し、DoS攻撃によるサービス停止などが典型例です。
対応は「検知・受付 → 初動(トリアージ)→ 分析・調査 → 封じ込め・復旧 → 報告 → 再発防止」という流れで進みます。検知・受付は、利用者からの申告や監視のアラートを一つの窓口で受け止める段階。初動(トリアージ)は、影響範囲と緊急度を素早く見積もって優先順位を決め、誰を呼ぶかを決める段階です。分析・調査で原因と侵入経路を突き止め、封じ込め・復旧で被害の拡大を止めてから業務を戻し、報告で経営層や関係先に伝え、最後に再発防止策を決めて標準やルールに反映します。
利用部門の人にとって一番大事なのは、最初の数分の行動です。マルウェア感染が疑われる端末は、まずネットワークから切り離します(LANケーブルを抜く、無線LANをオフにする)。ほかの端末やサーバへ広がるのを止めるためです。そして電源は切ってはいけません。メモリ上のデータや通信の状態といった揮発性の情報は、電源を切ると消えてしまい、原因究明ができなくなるからです。
ほかにやってはいけないこと。ログを消したり、感染ファイルを自分で削除したりしない(証拠が失われます)。自分だけで解決しようとしない(判断を誤ると被害が広がり、発覚も遅れます)。攻撃メールに返信しない、添付ファイルやリンクを確認のために開き直さない(アドレスが有効だと相手に教えることになります)。ランサムウェアの身代金は、払っても復元される保証がなく、支払いは推奨されません。迷ったら、まず上長と情報セキュリティ担当(CSIRT)へ報告する、が正解です。
証拠保全とディジタルフォレンジックスも覚えておきましょう。フォレンジックスは、法的な証拠として使えるようにデータを収集・分析することです。原本のディスクを直接いじらず複製(イメージ)を取り、ハッシュ値で改ざんされていないことを示し、誰が・いつ・何をしたかという取扱いの記録(証拠の連鎖)を残します。記録は時刻・担当者・実施内容・判断の理由をその都度書き残すのが基本で、あとから報告書を書くときの土台になります。
エスカレーションは、決められた基準にしたがって上位者や専門チームへ引き上げることです。「自分の手に負えないと感じたら上げる」ではなく、「この条件に当てはまったら上げる」とあらかじめ決めておきます。連絡先は、経営層、社内の利用者、取引先や委託元、監督官庁(個人データの漏えいなら個人情報保護委員会)、犯罪の疑いがあれば警察。公表するかどうかは、被害者の保護と二次被害の防止という観点から経営層が判断します。
再発防止のところで、インシデント管理と問題管理の違いも押さえておきます。インシデント管理の目的はサービスをできるだけ早く復旧させること(暫定対応でもよい)。問題管理の目的は根本原因を突き止めて、同じことが二度と起きないようにすることです。目の前の火を消すのがインシデント管理、火元を直すのが問題管理、と考えると分かりやすいでしょう。
| 段階 | やること | やってはいけないこと |
|---|---|---|
| 検知・受付 | 気づいたら決められた窓口へすぐ連絡する。時刻と状況を記録する | 様子を見る、自分の中で止める |
| 初動(トリアージ) | 影響範囲と緊急度を見積もり、優先順位と担当を決める | 感染端末の電源を切る(揮発性の証拠が消える) |
| 初動(封じ込め前) | 感染が疑われる端末をネットワークから切り離す | そのまま業務を続けて社内に広げる |
| 分析・調査 | ログとメモリを保全し、原因と侵入経路を調べる | ログや不審ファイルを削除する、原本を直接操作する |
| 封じ込め・復旧 | 拡大を止めてから、安全を確認して業務を戻す | 原因が分からないまま元に戻す |
| 報告 | 経営層・利用者・取引先・監督官庁・警察へ、基準に沿って連絡する | 自分だけで解決しようとする、事実を小さく見せる |
| 再発防止 | 根本原因に対する恒久対策を決め、ルールと教育に反映する | 担当者の注意不足で片づけて終わる |
| 全期間共通 | 対応の記録(時刻・担当・内容・判断理由)を残す | 攻撃メールに返信する、リンクや添付を開き直す |
- 情報セキュリティ事象
- システムやサービス、ネットワークの状態で、セキュリティに関係する何かが起きたことを示す出来事。まだ被害かどうかは分からず、調査の結果インシデントと判断されることもあれば、問題なしで終わることもある。
- 情報セキュリティインシデント
- 望ましくない、または予期しない情報セキュリティ事象のうち、事業運営を危うくし、情報セキュリティを脅かす可能性が高いもの。感染・不正アクセス・紛失・誤送信・改ざんなどが該当する。
- トリアージ
- 受け付けたインシデントの影響範囲と緊急度を短時間で見積もり、対応の優先順位と担当を決める初動の作業。もとは災害医療の用語で、限られた人手を重いものから順に割り当てるという考え方。
- 封じ込め
- 被害がこれ以上広がらないように、感染端末をネットワークから切り離す、侵害されたアカウントを停止する、通信を遮断するなどの手を打つこと。復旧より先に行うのが原則。
- 揮発性データ
- メモリ上の情報、実行中のプロセス、確立中の通信など、電源を切ると消えてしまうデータ。攻撃の痕跡が残っていることが多いため、感染端末の電源を切らずネットワークだけ切り離す。
- ディジタルフォレンジックス
- 不正アクセスや情報漏えいの原因究明・法的証拠の確保のために、機器やログのデータを保全し、分析して事実を明らかにする技術と手続の総称。原本は複製して扱う。
- エスカレーション
- あらかじめ決めた基準にしたがって、対応を上位者や専門チーム(CSIRTなど)へ引き上げること。判断が遅れると被害が広がるため、基準と連絡先を事前に決めておく。
- インシデント管理と問題管理
- インシデント管理はサービスの早期復旧が目的で、暫定的な回避策でもよい。問題管理は根本原因の究明と恒久対策による再発防止が目的。目的が違うので、別々の活動として管理する。
例題 業務用PCでウイルス対策ソフトの警告が出た。利用者が最初にすべきことは。
LANケーブルを抜く(無線LANをオフにする)などしてネットワークから切り離し、電源は入れたまま上長と情報セキュリティ担当へ連絡する。切り離しは感染の拡大を止めるため、電源を切らないのはメモリ上の証拠を残すため。
例題 サーバの再起動でサービスは戻ったが、原因は分かっていない。次にすることは。
インシデント管理としては復旧できたが、問題管理として根本原因を調査し、恒久対策を決める。原因不明のままでは同じ障害が再発する。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類2 情報セキュリティ管理(情報セキュリティインシデント管理)/JIS Q 27000(情報セキュリティ事象・インシデントの定義)
守る組織をつくる
誰が見張り、誰が対応をまとめ、困ったときはどこへ相談するのか。社内外の役割分担が分かるようになります。
CSIRT(Computer Security Incident Response Team)は、インシデントの報告を受け付け、トリアージし、社内の対応をまとめる組織です。技術的な調査だけでなく、経営層への報告、関係部門との調整、外部機関との窓口、注意喚起の発信までを担います。多くの企業では専任者だけで作るのではなく、情報システム部門・法務・広報・人事などから人を集めた横断チームとして作り、平時は教育や訓練、脆弱性情報の収集を行います。大事なのは「困ったらここへ連絡すればよい」という単一の窓口があることです。
SOC(Security Operation Center)は、ネットワークやサーバ、端末を24時間365日監視し、ログやアラートから攻撃の兆候を見つけ出す組織です。SOCの中心は「検知」と「分析」で、見つけた事象を報告するところまで。そこから先の「どう対応するかを決めて、社内をまとめて動かす」のがCSIRTです。SOCは目、CSIRTは司令塔、と覚えると区別しやすくなります。SOCは外部の専門事業者に委託することも多く、その場合でも社内にCSIRTがないと判断ができません。
PSIRT(Product Security Incident Response Team)は、自社が販売・提供する製品やサービスの脆弱性に対応するチームです。守る対象が社内のシステムではなく「自社製品を使っている顧客」である点がCSIRTと違います。脆弱性の届出を受け付け、修正プログラムを作り、顧客へ告知します。
外部の窓口も覚えます。JPCERT/CC(JPCERTコーディネーションセンター)は、インシデントの報告を受け付け、関係者間の調整や海外CSIRTとの連携、注意喚起の発信を行う組織。IPA(情報処理推進機構)は、コンピュータウイルス・不正アクセス・脆弱性関連情報などの届出を受け付ける公的な窓口です。NISC(内閣サイバーセキュリティセンター)は、政府の司令塔として国全体の戦略や基準づくりを担ってきた組織で、2025年7月に内閣官房の国家サイバー統括室(NCO)へ発展的に改組されました(司令塔としての役割は引き継がれています)。犯罪の疑いがある場合は、都道府県警察のサイバー犯罪相談窓口へ相談します。
情報共有の枠組みもあります。J-CSIP(サイバー情報共有イニシアティブ)は、参加組織がIPAを介して標的型攻撃などの情報を共有し、早期の気づきにつなげる仕組み。J-CRAT(サイバーレスキュー隊)は、標的型攻撃の被害が疑われる組織に対し、IPAが被害の拡大防止を支援する活動。ISAC(アイザック)は、金融ISAC・ICT-ISACのように業界ごとに作られた情報共有・分析組織です。自分の会社だけで攻撃の全体像を見ることはできないので、外とつながることが防御になります。
脆弱性情報の届出制度も押さえます。ソフトウェア製品やWebサイトの脆弱性を見つけた人は、IPAへ届け出ます。IPAは受付・分析を行い、製品の脆弱性についてはJPCERT/CCが開発者との調整や公表日の設定を行い、対策情報はJVN(脆弱性対策情報ポータルサイト)で公表されます。この一連の枠組みが「情報セキュリティ早期警戒パートナーシップ」です。見つけた人が勝手に公表しないこと、そして許可なく他社のシステムを試さないことが前提になります。
検知を支える道具としては、各種ログを集めて相関分析し、単体では気づけない攻撃の兆候をあぶり出すSIEM、端末側の不審な挙動を検知して調査・隔離まで行うEDR、そして改ざんされないよう保護されたログ管理の仕組みがあります。ログは「取っているだけ」では意味がなく、保存期間を決め、定期的に確認し、必要なときに追跡できる状態にしておくことが求められます。
最後に演習と訓練。標的型攻撃メール訓練は、開封してしまった人を責めるためのものではなく、開いたときに速やかに窓口へ報告できるかを確かめ、報告しやすい空気をつくるためのものです。机上訓練(ウォークスルー)は、想定シナリオに沿って関係者が集まり、連絡・判断・報告の流れを口頭で確認する演習で、手順書の穴や連絡先の古さが見つかります。訓練の結果は必ず手順の見直しに反映します。
| 区分 | 名称 | 主な役割 | 覚え方 |
|---|---|---|---|
| 社内 | CSIRT | インシデントの受付・トリアージ・対応調整・報告・外部連携 | 司令塔 |
| 社内 | SOC | ログとアラートの常時監視、攻撃の兆候の検知と分析 | 目 |
| 社内 | PSIRT | 自社製品の脆弱性受付、修正版の提供、顧客への告知 | 製品を守る |
| 外部 | JPCERT/CC | インシデント報告の受付、関係者間の調整、注意喚起、海外CSIRT連携 | 調整役 |
| 外部 | IPA | ウイルス・不正アクセス・脆弱性関連情報の届出受付、注意喚起 | 届出の窓口 |
| 外部 | NISC/NCO | 政府の司令塔として国の戦略・基準づくりを担う(2025年7月にNISCから国家サイバー統括室(NCO)へ改組) | 国の方針 |
| 外部 | 都道府県警察 | サイバー犯罪相談窓口。犯罪の疑いがあるときに相談・被害届 | 捜査 |
| 情報共有 | J-CSIP | IPAを介した参加組織間の標的型攻撃情報の共有 | 情報を配る |
| 情報共有 | J-CRAT | 標的型攻撃の被害が疑われる組織への支援(被害拡大防止) | 駆けつける |
| 情報共有 | ISAC | 金融ISACなど業界単位の情報共有・分析組織 | 業界の輪 |
- CSIRT
- インシデントの受付・トリアージ・対応の調整・外部機関との連絡・注意喚起を担う社内の中核チーム。平時は教育や訓練、脆弱性情報の収集を行う。単一の窓口として機能することが重要。
- SOC
- ネットワークや端末を常時監視し、ログやアラートから攻撃の兆候を検知・分析する組織。役割の中心は検知であり、対応方針の決定や社内調整はCSIRTが担う。外部委託されることも多い。
- PSIRT
- 自社が提供する製品・サービスの脆弱性に対応するチーム。守る対象が自社内ではなく製品の利用者である点がCSIRTと異なり、脆弱性の受付、修正版の提供、顧客への告知を行う。
- JPCERT/CC
- インシデントの報告を受け付け、関係者間の調整や海外のCSIRTとの連携、注意喚起の発信を行う一般社団法人。製品脆弱性では開発者との調整と公表日の設定を担当する。
- IPA
- 情報処理推進機構。ウイルス・不正アクセス・脆弱性関連情報などの届出を受け付ける公的な窓口で、J-CSIPの事務局やJ-CRATの活動、各種ガイドラインの公開も行っている。
- J-CSIP
- サイバー情報共有イニシアティブ。参加組織がIPAを介して標的型攻撃などの情報を共有し、他組織の被害の兆候を早期に把握できるようにする枠組み。共有情報は匿名化して展開される。
- J-CRAT
- サイバーレスキュー隊。標的型攻撃の被害が疑われる組織からの相談を受け、IPAが被害の拡大防止と早期対処を支援する活動。攻撃の連鎖を断ち切ることを狙いとする。
- JVN
- 脆弱性対策情報ポータルサイト。IPAとJPCERT/CCが共同で運営し、届出・調整を経た脆弱性の対策情報を公表する。利用者はここで自社が使う製品の対策状況を確認できる。
- SIEM
- さまざまな機器やソフトのログを一か所に集め、相関分析して攻撃の兆候を見つける仕組み。単体のログでは気づけない一連の動きを結びつけて検知し、調査の起点になる。
- EDR
- 端末(エンドポイント)の挙動を記録・監視し、不審な動きを検知して調査や隔離を行う仕組み。侵入されることを前提に、感染後にいかに早く気づいて広げないかを狙う対策。
例題 SOCを外部に委託していれば、社内にCSIRTは不要か。
不要とはいえない。SOCは検知と分析までで、対応方針の決定、社内の調整、経営層や関係先への報告は自社で判断するしかない。その役割を担うのがCSIRT。
例題 自社Webサイトの脆弱性を社外の人から知らされた。どう扱うか。
報告を受け付け、事実を確認して修正する。脆弱性関連情報はIPAへの届出制度があり、製品の脆弱性はJPCERT/CCが開発者と調整し、対策情報はJVNで公表される。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類2 情報セキュリティ管理(CSIRT・インシデント管理・脆弱性情報の取扱い)/情報セキュリティ早期警戒パートナーシップ(IPA・JPCERT/CC)
法令にもとづく報告と、監視のしくみ
個人データが漏れたときの報告義務と、組織を外から点検するシステム監査のルールが分かるようになります。
個人データの漏えい・滅失・毀損(あわせて漏えい等)が起きたとき、個人情報取扱事業者は、個人情報保護委員会への報告と、本人への通知を行う義務があります(個人情報保護法)。すべての漏えいが対象になるわけではなく、報告が必要になるのは次の4つの類型です。(1)要配慮個人情報が含まれる事態、(2)不正に利用されると財産的被害が生じるおそれがある事態(クレジットカード番号やログイン情報など)、(3)不正の目的をもって行われたおそれがある事態(不正アクセス、ランサムウェア、従業者による持ち出しなど)、(4)本人の数が1,000人を超える事態。実際に漏えいしたと確定していなくても、そのおそれがある段階で対象になります。
報告は2段階です。速報は、事態を知った後、速やかに(個人情報保護委員会の資料では発覚から概ね3〜5日以内が目安とされています)、その時点で分かっている範囲を報告します。確報は原則30日以内、(3)の不正の目的による類型は60日以内に、調査結果をまとめて報告します。分からないことがあるから報告しない、ではなく、まず速報を出すのが制度の考え方です。本人への通知も、事態の状況に応じて速やかに行います。連絡先が分からないなど通知が困難な場合は、ホームページでの公表や問合せ窓口の設置といった代替措置をとることが認められています。委託先で漏えいが起きた場合は、委託元へ通知することで委託先の報告義務が免除される扱いがあり、いずれにせよ報告そのものが消えるわけではありません。
経営層向けの指針としては、経済産業省とIPAが公開しているサイバーセキュリティ経営ガイドラインがあります。経営者が認識すべき3原則(経営者のリーダーシップ、自社だけでなく取引先を含めた対策、平時からの関係者との対話と情報共有)と、経営者がセキュリティ担当役員(CISO等)に指示すべき重要10項目からなり、体制の構築、リスクの把握、資源の確保、委託先の管理、インシデント発生時の緊急対応体制と復旧体制の整備、情報共有活動への参加などが並びます。セキュリティは技術の話ではなく経営の話だ、というのがこのガイドラインの土台です。
内部統制は、業務が適正に行われるように組織の中に組み込む仕組みのこと。職務分掌(一人に権限を集めない)、相互牽制、承認と記録、そしてITへの対応が柱になります。ITガバナンスは、経営陣がITの活用と統制の方向性を定め、実行を評価・監督して、企業価値の向上につなげる取組みです。統制を実際に回すのが現場、その方向を決めて監督するのが経営、という関係になります。
システム監査は、独立した立場のシステム監査人が、情報システムを点検・評価し、改善に向けた助言・勧告を行うものです。ここで最重要なのが独立性。監査人は、自分が設計・開発・運用に関与したシステムを監査してはいけません(自己監査の禁止)。外観上の独立性(被監査部門と利害関係がないこと)と、精神上の独立性(公正・客観的な判断を保つ姿勢)の両方が求められます。もう一つ、監査人は助言や勧告はしますが、対策そのものを実施する立場ではありません。改善を実施する責任は被監査部門にあります。監査人が自ら改善作業をしてしまうと、次の監査で自分の仕事を点検することになり、独立性が失われます。
監査の証拠になるのが監査証跡です。処理がいつ、誰によって、どのように行われたかを後から追跡できる記録(ログ、伝票、承認履歴など)で、監査人はこれを集めて監査調書としてまとめます。監査の手順は、監査計画の策定 → 予備調査(資料や体制の概要把握)→ 本調査(証拠の収集と評価)→ 評価・結論 → 監査報告書の提出 → フォローアップ(改善状況の確認)という流れです。フォローアップまでが監査であり、報告して終わりではありません。
監査の種類も整理しておきます。内部監査は、組織内の監査部門が自組織を対象に行うもので、経営に直結した改善につなげやすい一方、独立性の確保に工夫が要ります。外部監査は、組織の外の専門家が行うもので、客観性が高く、取引先や社会への説明に使えます。情報セキュリティ監査制度は、情報セキュリティ管理基準・情報セキュリティ監査基準にもとづいて行われる制度で、基準に照らして助言型または保証型の監査を実施します。
| 区分 | 項目 | 内容 |
|---|---|---|
| 漏えい等報告 | 対象(4類型) | 要配慮個人情報を含む/財産的被害のおそれ/不正の目的による行為/1,000人超 |
| 漏えい等報告 | 速報 | 事態を知った後、速やかに(発覚から概ね3〜5日以内が目安)判明分を報告 |
| 漏えい等報告 | 確報 | 原則30日以内。不正の目的による類型は60日以内 |
| 漏えい等報告 | 本人への通知 | 状況に応じて速やかに。困難なときは公表や問合せ窓口で代替可 |
| 監査手順 | 1 計画 | 監査の目的・範囲・重点・日程を定める |
| 監査手順 | 2 予備調査 | 資料や体制の概要を把握し、本調査の的を絞る |
| 監査手順 | 3 本調査 | 監査証跡を集め、事実を確かめて評価する |
| 監査手順 | 4 評価・結論 | 集めた証拠にもとづき結論を出し、監査調書にまとめる |
| 監査手順 | 5 報告 | 監査報告書として指摘事項と改善提言を伝える |
| 監査手順 | 6 フォローアップ | 改善が実施されたかを後から確認する |
| 監査人の立場 | 独立性 | 被監査部門と利害関係を持たない(外観)/公正客観に判断する(精神) |
| 監査人の立場 | 自己監査の禁止 | 自分が設計・開発・運用に関与したシステムは監査できない |
| 監査人の立場 | 助言と実施 | 助言・勧告は行うが、対策の実施は被監査部門の責任で行う |
- 漏えい等報告
- 個人データの漏えい・滅失・毀損またはそのおそれが生じたとき、個人情報保護委員会へ行う報告。要配慮個人情報、財産的被害のおそれ、不正の目的による行為、1,000人超の4類型が対象。
- 速報と確報
- 速報は事態を知った後、速やかに(発覚から概ね3〜5日以内が目安)、その時点で判明している内容を報告するもの。確報は原則30日以内(不正の目的による類型は60日以内)に調査結果をまとめて報告する。
- 本人への通知
- 漏えい等の事態を本人に知らせる義務。事態の状況に応じて速やかに行う。連絡先不明などで通知が困難なときは、公表や問合せ窓口の設置といった代替措置で代えることができる。
- サイバーセキュリティ経営ガイドライン
- 経済産業省とIPAが公開する経営者向けの指針。経営者が認識すべき3原則と、担当役員に指示すべき重要10項目からなり、体制整備・委託先管理・緊急対応体制などを求めている。
- 内部統制
- 業務が適正に行われることを確保するために組織に組み込む仕組み。職務分掌、相互牽制、承認と記録、ITへの対応などからなり、整備と運用の責任は経営者にある。
- システム監査人の独立性
- 被監査部門と利害関係を持たない外観上の独立性と、公正・客観的に判断する精神上の独立性。自分が開発・運用に関与したシステムを監査することはできない(自己監査の禁止)。
- 監査証跡
- 処理がいつ、誰によって、どのように行われたかを後から追跡できる記録。ログ、伝票、承認履歴などが該当し、監査人が事実を確かめる客観的な証拠になる。
- フォローアップ
- 監査報告書で指摘した事項について、改善が実施されたかを後から確認する活動。改善の実施責任は被監査部門にあり、監査人は状況を確かめて必要なら再度助言する。
例題 不正アクセスにより顧客500人分のメールアドレスが外部に流出したおそれがある。報告は必要か。
必要。人数は1,000人以下だが、不正の目的をもって行われたおそれがある事態に当たるため報告対象。速報を速やかに出し、確報は60日以内となる。
例題 情報システム部門で運用を担当していた人が、異動後すぐに同じシステムの監査を担当してよいか。
適切ではない。自分が運用に関与したシステムを監査することになり、自己監査の禁止に反して独立性が保てない。別の監査人が担当すべき。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類2:企業と法務 中分類2:法務/マネジメント(システム監査)/個人情報保護法(漏えい等の報告・本人への通知)/個人情報保護委員会 公表資料/サイバーセキュリティ経営ガイドライン(経済産業省・IPA)
情報セキュリティ対策
人的対策(教育・契約・入退社の手続)
どんなに高価な機器を入れても、扱う人が油断すれば情報は漏れます。教育・契約・手続という人的対策を、時期ごとに整理します。
情報セキュリティ対策は、大きく人的対策・技術的対策・物理的対策の三つに分けて考えます。人的対策とは、人の行動をあるべき方向へ向けるための対策で、教育と啓発、契約や規程による約束事、入社・異動・退職といった節目の手続がその中心です。情報セキュリティリーダーの仕事は機器の設定よりも、この人的対策を回し続けることに重心があります。
教育は、相手によって伝えるべきことが変わります。新入社員には、まず自社の情報セキュリティ方針と、業務で守るべき規程(持出しの申請、パスワードの扱い、SNSでの発信)を、業務を始める前に伝えます。管理職には、部下の権限を承認する立場としての責任、部下の様子の変化への気づき、インシデント発生時に報告を受けてエスカレーションする役割を伝えます。全社員には、最新の攻撃の手口と、自社で実際に起きた事例(誰が悪いかではなく、どこで防げたか)を、年1回など定期的に繰り返します。一度やって終わりにせず、繰り返すことが効果を生みます。
標的型攻撃メール訓練は、業務を装った訓練用メールを従業員に送り、開封や添付ファイルの実行、リンクのクリックがどれくらい起きるかを測る訓練です。目的は開封した人を責めることではなく、あやしいと思ったときに『開かない』『すぐ報告する』という行動を体に覚えさせることと、報告の窓口と経路が実際に機能するかを確かめることにあります。訓練の結果は個人の処罰に使わず、組織全体の傾向として教育の改善につなげます。開封率だけでなく報告率を指標にするのが良い訓練です。
約束事は文書で結びます。従業員とは入社時に秘密保持契約(NDA)を結び、退職後も一定期間は秘密を守る義務が続くことを明示します。アルバイトや派遣社員も、雇用形態にかかわらず情報に触れる以上は同じ教育と誓約が必要です。委託先には、契約書に秘密保持、再委託の可否と条件、事故時の報告義務、契約終了時のデータ返却または消去を定め、自社と同等の管理水準を求めます。契約を結んだら終わりではなく、報告書の確認や訪問などで実施状況を確かめます。
節目の手続では、入社時に必要最小限の権限を付与し、異動時には旧部署の権限を必ず削除してから新部署の権限を与えます。追加だけを繰り返すと、長く勤めた人ほど権限が積み上がる『権限の蓄積』が起き、内部不正や誤操作の被害を大きくします。退職時には、最終出社日までにアカウントの削除または無効化と、貸与したPC・スマートフォン・IDカード・鍵・書類の回収を行い、秘密保持義務が退職後も続くことを改めて確認します。退職者のアカウントが残っていると、外部から正規の利用者として侵入されても気づけません。
内部不正への備えでは、動機・機会・正当化という三つがそろうと不正が起きやすいと考えます。組織にできるのは主に『機会』を減らすことで、権限を絞る、一人だけで完結させない、ログを取得していることを従業員に周知する、といった対策が抑止として働きます。見られているという意識が生まれるだけで不正は減ります。逆に、監視していることを隠すと抑止にならず、後から発覚したときの不信も招くため、監視の目的と範囲は規程で明らかにして周知します。
退職時に抜けやすい項目をチェックリストにする
退職手続チェックリスト(最終出社日までに完了させる) 1. 業務システム・メール・クラウドサービスのアカウントを無効化する 2. 共用ID・特権IDのパスワードを変更する(本人が知っている前提で) 3. 入館用IDカード、鍵、社章を回収し、入退室権限を削除する 4. 貸与したPC、スマートフォン、USBメモリ、記録媒体を回収する 5. 業務データの引継ぎ先を決め、私物端末や個人アカウントに残していないか確認する 6. 秘密保持義務が退職後も続くことを説明し、誓約書に署名を得る 7. 上記の完了を人事部門と情報システム部門の双方で記録する
| 時期 | 主な対策 | ねらい |
|---|---|---|
| 入社時 | 方針と規程の説明、秘密保持契約(NDA)の締結、必要最小限の権限付与 | 業務を始める前に守るべき線を示し、権限を絞って始める |
| 在職中(全社員) | 定期教育、標的型攻撃メール訓練、事例の共有、注意喚起の掲示 | 手口の変化に追随し、報告する行動を定着させる |
| 在職中(管理職) | 権限承認の責任、部下の様子への気づき、報告を受けたときの対応の教育 | 承認とエスカレーションの担い手を育てる |
| 異動時 | 旧部署の権限の削除、新部署の権限の付与、引継ぎ資料の扱いの確認 | 権限の蓄積を防ぎ、必要な範囲だけに保つ |
| 退職時 | アカウントの削除・無効化、貸与品(PC・IDカード・鍵・書類)の回収、秘密保持義務の再確認 | 退職後の不正利用と持出しを防ぐ |
| 委託先・派遣・アルバイト | 契約への秘密保持と再委託条件の明記、同等の教育と誓約、実施状況の確認 | 自社と同じ水準を社外にも及ぼす |
- 人的対策
- 人の行動に働きかける対策の総称。教育・訓練、規程や契約による取決め、入社・異動・退職の手続、監視の周知による抑止などが含まれる。機器の導入では代えられない領域を担う。
- 標的型攻撃メール訓練
- 業務を装った訓練メールを従業員に送り、開封や報告の行動を確かめる訓練。処罰ではなく、開かない・すぐ報告するという行動の定着と、報告窓口が実際に機能するかの確認が目的。
- 秘密保持契約(NDA)
- 業務で知った秘密を外部に漏らさないことを約束する契約。従業員とは入社時に、取引先とは取引開始時に結ぶ。退職後や契約終了後も一定期間は義務が続くと定めるのが一般的。
- 権限の蓄積
- 異動のたびに権限を追加するだけで旧権限を削除しないため、本人の業務に不要な権限が積み上がる状態。最小権限の原則に反し、内部不正や誤操作の被害を広げるので、異動時の削除で防ぐ。
- 組織における内部不正防止ガイドライン
- IPAが公開している、内部不正の防止と早期発見のための指針。経営者の関与、権限の管理、証拠となる記録の確保、退職者への対応、相談窓口の設置などを具体的に示している。
- 抑止
- 不正をしようとする気持ちを思いとどまらせる働き。ログを取得していることの周知、罰則の明示、監視カメラの設置などが該当し、実際に止める『予防』とは役割が異なる。
例題 標的型攻撃メール訓練で開封率が前回より上がってしまった。まず何をすべきか。
開封した人の氏名を公表したり処罰したりせず、どの部署でどんな件名に反応したのかを分析し、教育内容と注意喚起の出し方を見直す。あわせて報告率(あやしいと気づいて窓口に連絡した割合)も確認する。訓練は評価ではなく改善のための道具である。
例題 退職者のアカウントを『念のため3か月残す』と言われた。どう答えるか。
残すなら無効化(ログインできない状態)にしたうえで、メールの転送先や引継ぎ担当者を決める。ログインできる状態で放置すると、本人以外に使われても正規の利用として記録されるため検知が難しく、退職時のアカウント処理は最終出社日までに行うのが原則だと説明する。
例題 委託先の担当者が『作業効率のため、一部を別の会社に手伝わせたい』と言ってきた。
再委託は契約で可否と条件を定めているはずなので、まず契約内容を確認する。認める場合も、書面での事前承認、再委託先にも同等の秘密保持と管理水準を課すこと、責任は元の委託先が負うことを条件にする。担当者間の口頭の了解で進めさせてはならない。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類4 情報セキュリティ対策(人的セキュリティ対策・啓発活動)/JIS Q 27002(人的資源のセキュリティ)/IPA 組織における内部不正防止ガイドライン
技術的対策と多層防御(入口・内部・出口)
ファイアウォールだけでは守れません。入口・内部・出口のどこで何を止めるのかという地図を持つと、対策の名前が意味を持って見えてきます。
ファイアウォール(FW)は、社内ネットワークとインターネットの境界に置き、通す通信と通さない通信を選り分ける仕組みです。基本となるパケットフィルタリングは、送信元と宛先のIPアドレス、ポート番号、プロトコルといったヘッダの情報を見て、あらかじめ決めたルールに従って許可または拒否します。ルールは上から順に評価され、最初に一致したルールが適用されます。そして最後には『どのルールにも一致しない通信はすべて拒否する』という暗黙の拒否を置くのが原則です。許可するものを列挙し、それ以外は通さないという考え方をホワイトリスト方式と呼びます。
ステートフルインスペクションは、通信の状態(コネクションの確立から終了までの流れ)を記憶し、内部から出ていった通信に対する応答パケットを動的に許可する方式です。一つ一つのパケットを独立に見るより安全で、戻りの通信のためにポートを広く開けておく必要がなくなります。外部に公開するWebサーバやメールサーバは、社内LANともインターネットともファイアウォールで隔てた緩衝地帯であるDMZに置きます。公開サーバが乗っ取られても、そこから社内LANへ直接入れないようにするためです。
境界だけでなく、守る対象ごとに専用の仕組みがあります。WAFはWebアプリケーションの前に置き、SQLインジェクションやクロスサイトスクリプティングのような、アプリの作りを狙う攻撃を通信の中身から見つけて遮ります。IDSは不正な通信や兆候を検知して知らせる装置、IPSは検知に加えてその通信を遮断する装置です。プロキシは社内から外部への通信を代理し、アクセス先の記録やURLフィルタリング・コンテンツフィルタリングによる制限を行います。EDRは、ネットワークではなくPCやサーバといった端末(エンドポイント)の動きを常時記録し、侵入された後のあやしい挙動を見つけて、隔離や調査を助けます。未知のファイルを隔離した環境で実際に動かして安全か確かめる仕組みがサンドボックスです。
対策は一つに頼らず重ねます。これが多層防御です。入口対策は、外からの侵入や不正なメールを入れないための対策で、FW、メールのフィルタリング、送信ドメイン認証(SPF・DKIM・DMARC)、アンチウイルスとパターンファイルの更新、サンドボックスなどが当たります。内部対策は、侵入されたことを前提に被害の広がりを抑える対策で、ネットワークの分割、権限の最小化、重要データの暗号化、ログの取得と監視、EDRによる挙動の検知、社内サーバへの多要素認証などです。出口対策は、盗んだ情報を外へ出させない、外部の指令サーバと通信させないための対策で、外向き通信のプロキシ経由の強制と記録、不審な宛先への通信遮断、DLPによる機密情報の送信検知、大量送信の検知などが当たります。
通信そのものを守る技術も欠かせません。WebアクセスはTLSで暗号化し、拠点間や在宅勤務からの接続にはVPNを使います。IPsecはIP層で暗号化と認証を行う仕組みで、拠点間接続によく使われます。無線LANでは暗号化方式の選択が重要で、WEPは解読方法が知られており使ってはいけません。現在はWPA2、より新しいものではWPA3を使います。このほか、社内に持ち込まれた端末をいったん別のネットワークに入れ、更新状況やウイルス対策の状態を確認してから社内に入れる検疫ネットワーク、機器やソフトウェアの状態を把握する資産管理ツール、社員が勝手に使うクラウドサービスの利用状況を可視化し統制するCASBも、管理者の道具として押さえておきます。
ファイアウォールのルール表の例(上から順に評価し、最後の5番が暗黙の拒否に当たる)
番号 送信元 宛先 サービス 動作 ------------------------------------------------------ 1 社内LAN DMZ:Webサーバ TCP/443 許可 2 社内LAN インターネット TCP/80,443 許可 3 インターネット DMZ:Webサーバ TCP/443 許可 4 インターネット 社内LAN すべて 拒否 5 すべて すべて すべて 拒否
| 対策 | 主に見ているもの | 置く場所 | 得意なこと |
|---|---|---|---|
| ファイアウォール | IPアドレス・ポート番号・プロトコル | ネットワークの境界 | 通してよい通信だけに絞る |
| WAF | HTTP通信の中身(要求の内容) | Webサーバの前 | Webアプリの脆弱性を狙う攻撃を防ぐ |
| IDS | 通信の内容や振る舞いの兆候 | 監視対象のネットワーク | 攻撃の兆候を検知して知らせる |
| IPS | 通信の内容や振る舞いの兆候 | 通信経路上 | 検知した通信をその場で遮断する |
| プロキシ | 社内から外部へのアクセス先 | 内部と外部の間 | アクセス先の記録と制限(URLフィルタ) |
| EDR | 端末内部の動作(プロセス・通信・変更) | PC・サーバなどの端末 | 侵入後のあやしい挙動の検知と隔離 |
- パケットフィルタリング
- IPアドレス、ポート番号、プロトコルなどヘッダの情報を見て通信を許可・拒否するファイアウォールの基本方式。ルールは上から順に評価し、どれにも一致しない通信は暗黙の拒否で通さない。
- ステートフルインスペクション
- 通信の状態を記憶し、内部から出ていった通信に対する応答パケットを動的に許可する方式。パケットを1個ずつ独立に判断する方式より安全で、戻り通信のためにポートをあらかじめ広く開けておく必要がない。
- DMZ
- インターネットからも社内LANからもファイアウォールで隔てた緩衝地帯のネットワーク。公開Webサーバやメールサーバを置き、外部からの通信はDMZまでにとどめて、これらが侵害されても社内LANへ直接侵入されないようにする。
- WAF
- Webアプリケーションの前段に置き、通信の中身を見てSQLインジェクションなどアプリの脆弱性を狙う攻撃を遮る仕組み。IPアドレスやポートしか見ないファイアウォールでは防げない攻撃を担当する。
- IDS/IPS
- IDSは不正な通信や攻撃の兆候を検知して管理者に知らせる装置。IPSは検知に加えてその通信を自動で遮断する装置。検知のみか遮断まで行うかが両者の違い。
- EDR
- PCやサーバなど端末の動作を常時記録し、侵入後のあやしい挙動を検知して、端末の隔離や原因調査を支援する仕組み。侵入を前提とする内部対策の代表で、入口で防ぐ製品とは役割が違う。
- 多層防御
- 入口・内部・出口など複数の段階に対策を重ね、一つ破られても被害が広がらないようにする考え方。単一の対策に依存しないことが要点で、入口対策だけでは侵入後に無防備になる。
- DLP
- Data Loss Preventionの略。あらかじめ定めた機密情報の特徴を手掛かりに、メール送信や外部媒体への書出しなど情報が外へ出る動きを検知・制限する仕組み。出口対策として使われる。
- CASB
- 利用者とクラウドサービスの間に立ち、どのクラウドが誰にどう使われているかを可視化し、統一した方針で制御する仕組み。無断利用(シャドーIT)の把握と統制に用いる。
- 検疫ネットワーク
- 社内LANに接続しようとする端末を、いったん隔離したネットワークに入れ、OS更新やウイルス対策の状態を確認してから接続を許可する仕組み。基準を満たさない端末は修正後に接続させる。
例題 上のルール表で、インターネット上の利用者が社内のファイルサーバ(社内LAN、TCP/445)へ接続しようとした。通信は許可されるか。
許可されない。1番から順に見ると、1番と2番は送信元が社内LANなので一致しない。3番は宛先がDMZのWebサーバなので一致しない。4番で送信元がインターネット、宛先が社内LANに一致し、動作は拒否となる。仮に4番がなくても5番ですべて拒否されるため、いずれにせよ通らない。
例題 『入口対策はしているので内部対策は不要』という意見にどう答えるか。
入口対策は侵入の確率を下げるだけで、ゼロにはできない。標的型攻撃のように利用者をだまして入ってくる手口では境界を素通りされる。侵入された後に被害を広げないための内部対策(権限の最小化、ネットワーク分割、ログ監視、EDR)と、情報を持ち出させない出口対策を重ねるのが多層防御の考え方だと説明する。
例題 サンドボックスと検疫ネットワークは何が違うか。
サンドボックスは、あやしいファイルを隔離した環境で実際に動かして危険かどうかを判定する仕組みで、未知のマルウェア対策に使う。検疫ネットワークは、社内LANにつなごうとする端末を隔離したネットワークで検査し、OS更新やウイルス対策が基準を満たしてから接続させる仕組みで、対象は端末の状態である。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類4 情報セキュリティ対策(マルウェア対策・不正アクセス対策・技術的セキュリティ対策)/JIS Q 27002(通信のセキュリティ)
物理的対策と持出し・持込みの管理
情報は建物の中にもあります。入退室、机の上、可搬媒体、紙。手で触れられる範囲を守るのが物理的対策です。
物理的対策は、情報資産が置かれている場所そのものを守る対策です。まず建物や部屋を重要度で区画に分けます。誰でも入れる受付、社員だけが入れる執務室、限られた担当者だけが入れるサーバ室、というように層を作り、奥へ行くほど厳しい認証を課します。区画の境目には施錠、IDカードによる入退室管理、生体認証などを置き、入退室の記録を残します。記録は入室と退室を対で残すことが重要で、いつ誰がどこにいたかを後から確かめられるようにします。
入退室管理でよく問われるのが共連れ(ピギーバック)です。正規の利用者が扉を開けた直後に、認証を受けていない人が一緒に入ってしまうことを指し、記録の上では一人しか入っていないことになるため危険です。対策としては、入退室を対で記録させるアンチパスバック(入室記録のない人は退室できない、退室記録のない人は再入室できないという制御)、一人ずつ通す構造の扉(サークルゲートやマントラップ)、警備員や監視カメラによる確認、そして『知らない人を一緒に通さない』という従業員教育を組み合わせます。技術と人の両方が要るところです。
執務室の中では、クリアデスクとクリアスクリーンを徹底します。クリアデスクは、離席時や退社時に書類や記録媒体を机の上に放置せず、施錠できる場所にしまうことです。クリアスクリーンは、離席時に画面をロックし、内容を見られないようにすることです。あわせて、ノートPCの盗難を防ぐセキュリティワイヤ、周囲からの視線を遮るのぞき見防止フィルタ、来客の動線を執務室から分けることなども有効です。ICカードなどについて、内部の情報を無理に読み出そうとすると壊れて読めなくなるといった、解析を難しくする性質を耐タンパ性といい、機器そのものの物理的な守りとして押さえておきます。
可搬媒体の管理は情報漏えい対策の要です。USBメモリやノートPCの持出しは、申請と承認を必要とし、いつ・誰が・何を・どこへ持ち出したかを台帳に記録します。持ち出すデータは暗号化し、必要最小限にとどめ、返却時には確実に消去します。持込みも同様に管理し、私物のUSBメモリを社内のPCに挿すことは、マルウェアの持込み経路になるため禁止するのが一般的です。利用しない機器のUSBポートを物理的または設定で塞ぐ方法もあります。紙媒体も情報資産です。重要な書類は施錠できるキャビネットに保管し、廃棄するときはシュレッダーや溶解処理を使います。裏紙としての再利用や、そのままごみ箱に捨てる行為は禁止します。オフィスの外に出したごみから情報を得る手口をスキャベンジング(ごみ箱あさり)といいます。
可用性を守る物理的対策も忘れてはいけません。停電で機器が止まらないようにする無停電電源装置(UPS)は、瞬時の停電を乗り切り、長い停電では機器を安全に停止させる時間を稼ぎます。長時間の停電に備えるなら自家発電装置が必要です。地震に備えて免震・耐震の構造にする、サーバラックを固定する、水害の恐れがある地階に重要機器を置かない、といった配置の判断も物理的対策に含まれます。
持出し台帳の例(いつ・何を・どこへ・暗号化の有無・誰が承認したかを残す)
申請日 媒体 持出先 暗号化 承認 ------------------------------------------------ 08-03 USBメモリ A社(打合せ) あり 課長 08-05 ノートPC 自宅(在宅) あり 課長 08-07 紙資料 B社(提案) - 部長
| 物理的対策 | 主に防ぐ脅威 | 補足 |
|---|---|---|
| 区画分け(受付・執務室・サーバ室) | 部外者の重要区画への侵入 | 奥の区画ほど厳しい認証を課す |
| IDカード・生体認証による入退室管理 | なりすまし入室、記録の欠落 | 生体認証はカードの貸し借りを防げる |
| アンチパスバック・一人ずつ通す扉 | 共連れ(ピギーバック) | 教育と監視カメラを併用する |
| クリアデスク・クリアスクリーン | 書類の盗み見・持去り、画面ののぞき見 | 離席時と退社時の習慣にする |
| セキュリティワイヤ・施錠キャビネット | ノートPCや書類の盗難 | 持ち去りに時間をかけさせて抑止する |
| のぞき見防止フィルタ | 肩越しののぞき見(ショルダーハッキング) | 社外や公共の場での作業に有効 |
| シュレッダー・溶解処理 | スキャベンジング(ごみからの情報収集) | 裏紙利用の禁止とあわせて運用する |
| UPS・自家発電装置・免震構造 | 停電や地震による停止(可用性の喪失) | 可用性を守るのも情報セキュリティ対策 |
- 共連れ(ピギーバック)
- 認証を受けた人が扉を開けた直後に、認証していない人が続いて入室してしまうこと。入退室記録と実際の在室者がずれるため、扉の構造・監視・教育を組み合わせて防ぐ。
- アンチパスバック
- 入室記録のない利用者の退室を認めない(またはその逆を認めない)制御。入退室を対で記録させることで、共連れやIDカードの貸し借りを抑止する。
- クリアデスク・クリアスクリーン
- 離席時や退社時に、書類や記録媒体を机上に放置せず施錠保管すること(クリアデスク)と、画面をロックして内容を見られないようにすること(クリアスクリーン)。
- 耐タンパ性
- 内部の情報を不正に読み出そうとしたり分解しようとしたりすると、動作しなくなる、情報が消えるなどして解析を困難にする性質。ICカードやセキュリティモジュールに求められる。
- スキャベンジング
- ごみ箱や廃棄物をあさって、書類や記録媒体から情報を得る手口。シュレッダーや溶解処理による確実な廃棄と、書類の裏紙利用の禁止が対策となる。
- UPS(無停電電源装置)
- 停電時に一定時間だけ電力を供給し続ける装置。瞬時の停電では稼働を維持し、長い停電では機器を安全に停止させる時間を確保する。長時間の停電には自家発電装置が必要。
例題 サーバ室の入退室記録に、入室だけあって退室のない社員がいた。何が疑われるか。
退室時にカードをかざさずに他人と一緒に出た(共連れ)か、記録の運用が守られていない可能性がある。記録が対になっていないと在室者を把握できず、災害時の安否確認にも支障が出る。アンチパスバックの導入や、一人ずつ通す扉、教育の再徹底を検討する。
例題 私物のUSBメモリを業務PCに挿して資料を持ち帰ろうとしている同僚を見かけた。
私物媒体の接続はマルウェアの持込みと情報の無断持出しの両方につながるため、規程で禁止されているのが通常である。その場で止め、必要な持出しであれば申請と承認を経て、会社が管理する暗号化された媒体を使うか、許可されたクラウド経由にするよう案内する。
例題 重要書類を捨てるとき、シュレッダーにかければ十分か。
細かく裁断できるシュレッダーであれば通常は十分だが、特に機密性の高い書類は溶解処理を委託する方法もある。委託する場合は、回収から処理までの管理と処理証明書の受領を条件にする。裁断前の書類を回収箱に長く放置しないことも重要である。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類4 情報セキュリティ対策(物理的セキュリティ対策・情報漏えい対策)/JIS Q 27002(物理的及び環境的セキュリティ)
アクセス権とログの運用、情報漏えい対策
権限は与えるより見直すほうが難しく、ログは取るより守るほうが難しい。日々の運用で効く型を身につけます。
アクセス権の設計は、最小権限の原則とNeed-to-Knowの考え方から始めます。最小権限とは、業務に必要な最小限の権限だけを与えること、Need-to-Knowとは、知る必要のある人だけが情報にアクセスできるようにすることです。権限は職務や役割ごとに定義し、個人ごとに例外を積み上げないようにします。そして、与えた権限は必ず定期的に棚卸し(見直し)をします。異動や退職、プロジェクトの終了で不要になった権限が残っていないか、部門長など業務を分かる人が確認し、不要なものを削除します。棚卸しは年1回など時期を決めて実施し、実施した記録を残します。
システム管理者が使う特権ID(管理者権限を持つID)は、特に厳しく管理します。共用せず個人に割り当てる、やむを得ず共用する場合は使用の申請と承認を必要として貸出しと返却を記録する、使用時の操作ログを必ず取得する、パスワードを定期的に変更する、通常業務では特権IDを使わない、といった運用が求められます。承認する人と実行する人を分ける職務分掌も、内部不正を防ぐうえで効果があります。
ログは、何かが起きたときに事実を確かめる唯一の手掛かりです。誰がいつ何をしたかが分かるように、ログイン成功と失敗、重要データへのアクセス、権限の変更、管理者操作、外部への通信などを記録します。取得するだけでは足りず、改ざんや削除ができないように保護すること(書込み専用の領域や別のログサーバへの集約、アクセス権の制限)と、定期的に確認すること(見ていないログは抑止にも検知にもならない)が重要です。時刻がずれていると複数の機器のログを突き合わせられないため、時刻同期も欠かせません。保管期間は、法令や自社の規程、事故発覚までの時間差を考えて決め、期間中は消さない運用にします。
脆弱性への対応では、公開された修正プログラム(パッチ)を適用します。すべてを同時には適用できないため、優先順位を付けます。判断の材料は、外部に公開されているか、悪用が実際に確認されているか(実際の攻撃が観測されている脆弱性は最優先)、深刻度の評価、対象資産の重要度です。適用前に検証環境で影響を確かめ、適用できない事情がある場合は、通信を制限する、監視を強めるといった代替策(緩和策)を取ります。前提として、どの機器にどのソフトウェアが入っているかを把握する資産の棚卸しができていなければ、適用漏れは避けられません。
情報漏えいの原因として非常に多いのがメールの誤送信です。宛先の確認を送信前に声に出す、複数人に送るときは宛先が互いに見えないようBCCを使う、送信を数分保留して取り消せるようにする、大量の宛先には配信システムを使う、といった対策を組み合わせます。添付ファイルの扱いでは、パスワード付きZIPファイルを送り、そのパスワードを直後に別のメールで送る方式、いわゆるPPAPが長く使われてきましたが、問題が多い方式です。同じ経路で送るためメールを盗み見られれば両方とも入手される、宛先を間違えれば暗号化ファイルもパスワードも同じ誤った相手に届く、ZIPが暗号化されているとウイルス対策ソフトやゲートウェイが中身を検査できずマルウェアの侵入を許す、受信側の手間が大きい、といった点です。現在は、アクセス権を管理できるファイル共有サービスの利用や、S/MIMEなどによるメール自体の暗号化、TLSによる経路の暗号化に置き換えることが推奨されます。
クラウドサービスでは、設定ミスによる意図しない公開が大きな事故につながります。共有範囲を『リンクを知っている全員』や『インターネットに公開』にしたまま放置すると、検索エンジンから見つかることもあります。既定値のまま使わず、共有範囲を作成時に確認し、定期的に棚卸しします。従業員が会社の承認を得ずに使うクラウドサービスやアプリをシャドーITといい、管理の目が届かないため危険です。私物端末を業務に使うBYODを認める場合は、利用条件を規程で定め、MDM(モバイル端末管理)で画面ロックや暗号化を強制し、紛失時に遠隔からロックやデータ消去ができるようにします。印刷物の放置も見落としがちで、共用プリンタではICカードをかざしてから出力する認証印刷が有効です。
アクセス権設定表の例(最小権限にもとづき、必要のない組合せは不可にする)
利用者(役割) 人事DB 給与DB 部内共有 全社共有 -------------------------------------------------------- 人事部長 参照可 参照可 更新可 参照可 人事担当者 更新可 不可 更新可 参照可 営業担当者 不可 不可 不可 参照可 システム管理者 不可 不可 不可 参照可
| 区分 | 原則 | 具体例 |
|---|---|---|
| アクセス権 | 最小権限の原則 | 業務に必要な操作だけを許可し、既定は不可にする |
| アクセス権 | Need-to-Know | 役職ではなく業務上の必要性で判断する |
| アクセス権 | 定期的な棚卸し | 年1回、部門長が一覧を確認し不要な権限を削除する |
| アクセス権 | 異動・退職時の即時変更 | 旧部署の権限を削除してから新権限を付与する |
| 特権ID | 限定・記録・分離 | 申請と承認、貸出返却の記録、操作ログの取得、通常業務では使わない |
| ログ | 何を残すか | ログイン成功と失敗、重要データへのアクセス、権限変更、管理者操作、外部通信 |
| ログ | 改ざんさせない | 別サーバへの集約、変更できない領域への保存、アクセス権の制限、時刻同期 |
| ログ | 見る・残す | 定期的に確認し、規程で定めた期間は消さずに保管する |
- 最小権限の原則
- 利用者やプログラムに、業務の遂行に必要な最小限の権限だけを与える考え方。与えすぎた権限は内部不正や誤操作、アカウント乗っ取り時の被害を大きくする。
- Need-to-Know
- 知る必要のある人だけが情報にアクセスできるようにする原則。役職が高いから何でも見てよい、ではなく、その業務に必要かどうかで判断する。
- アクセス権の棚卸し
- 現在付与されている権限を一覧にし、業務内容を把握している責任者が必要性を確認して不要な権限を削除する定期的な作業。異動・退職・プロジェクト終了に伴う残存権限を発見できる。
- 特権ID
- システムの設定変更やすべてのデータへのアクセスができる管理者権限のID。共用を避け、使用の申請・承認・記録、操作ログの取得、通常業務での不使用を徹底する。
- ログの保全
- 取得したログを改ざん・削除されないように保護すること。別のログサーバへの集約、書込み後に変更できない領域の利用、アクセス権の制限、時刻同期などで実現する。
- PPAP
- パスワード付きZIPファイルをメールで送り、そのパスワードを別のメールで送る方式の通称。同じ経路のため盗聴や誤送信に弱く、暗号化により受信側でウイルス検査ができない問題がある。
- シャドーIT
- 従業員が組織の承認を得ずに業務で使うIT機器やクラウドサービス。管理者が把握できないため、情報の所在が分からなくなり、退職時の回収も設定の確認もできない。
- MDM(モバイル端末管理)
- スマートフォンやタブレットを組織が一元管理する仕組み。画面ロックや暗号化の強制、アプリの制限、紛失時の遠隔ロックやデータ消去などを行う。
例題 上のアクセス権設定表で、人事担当者が給与DBを参照できないのはなぜか。
その業務に給与データを見る必要がないからである。同じ人事部門でも、担当している業務が異なれば必要な情報は異なる。役職や所属ではなく業務上の必要性で判断するのがNeed-to-Knowであり、必要になったときに申請と承認を経て一時的に付与し、終わったら削除する運用が望ましい。
例題 取引先へ個人情報を含むファイルを送りたい。PPAPは使うべきか。
使うべきではない。ZIPとパスワードを同じメール経路で送るため、盗聴されれば両方が渡り、宛先を間違えれば両方が誤った相手に届く。さらに暗号化されたZIPは受信側のウイルス検査を通り抜ける。アクセス権と有効期限を設定できるファイル共有サービスを使い、通知は別の手段で行うのが望ましい。
例題 『ログは1年分取っているから大丈夫』と言われた。確認すべき点は何か。
取得しているだけでなく、改ざん・削除ができない形で保護されているか、定期的に確認しているか、機器間で時刻が同期しているか、必要な種類のログ(ログイン失敗、権限変更、管理者操作など)が含まれているかを確認する。誰も見ていないログは抑止にも早期発見にもつながらない。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類4 情報セキュリティ対策(アクセス管理・情報漏えい対策)/JIS Q 27002(アクセス制御・運用のセキュリティ)
利用者としての実践(今日からできる対策)
規程を守るのは現場の一人ひとりです。自分の手元で今日からできることと、迷ったときの相談先を確認します。
パスワードは、長さが最も効きます。単語をいくつかつないだ長い文(パスフレーズ)にする、他人が推測できる誕生日や名前を使わない、そして何より使い回さないことが大切です。どこか一つのサービスから漏れたIDとパスワードを他のサービスで試す攻撃があるため、使い回しは一気に被害が広がります。数が多くて覚えられない場合は、信頼できるパスワード管理ソフトを使う、あるいは会社が認めた方法で管理します。付箋に書いて画面に貼る、共用ファイルに一覧を置くといった管理は避けます。可能なサービスでは多要素認証を有効にすると、パスワードが漏れても不正ログインを防ぎやすくなります。
フィッシングは、実在する企業や社内の部署をかたって、偽サイトへ誘導しIDやパスワード、クレジットカード番号を入力させる手口です。見分けるこつは、メールのリンクをクリックせず、普段使っているブックマークや公式アプリから確認すること、『至急』『アカウントを停止します』と急がせる文面を疑うこと、送信元アドレスやリンク先のドメインをよく見ることです。日本語が自然になっているものも多く、文面の不自然さだけでは判断できません。少しでも迷ったら操作せず、社内の窓口に相談するのが正解です。
外出先の公衆Wi-Fiは、暗号化されていないものや、正規のものに似せた偽のアクセスポイントがあり得ます。業務で使う場合は、会社が用意したVPNを通す、あるいはスマートフォンのテザリングを使うほうが安全です。やむを得ず使うときも、IDやパスワードを入力する操作は避け、通信がTLSで暗号化されている(アドレスがhttpsで始まる)ことを確認します。周囲からの画面ののぞき見にも注意し、のぞき見防止フィルタを活用します。
テレワークでは、自宅も職場と同じ扱いになります。業務用PCを家族と共用しない、離席時は画面をロックする、web会議で画面を共有するときは関係のない資料を閉じておく、家族に画面や会話が見聞きされない場所で行う、といった配慮が必要です。自宅のルータも見落とされがちで、初期パスワードのまま使わない、ファームウェアを更新する、無線LANの暗号化をWPA2以上にする、といった点を確認します。業務データは会社が許可した場所にだけ保存し、私物のクラウドストレージには置きません。
スマートフォンは小さなPCです。画面ロックを必ず設定し、OSとアプリを最新に保ちます。アプリを入れるときは公式のストアからにして、連絡先や位置情報、カメラなどの権限要求が、そのアプリの機能に照らして妥当かを確認します。提供元のはっきりしないアプリ(いわゆる野良アプリ)や、正規のストア以外から入手したアプリは入れません。紛失に備えて画面ロック、遠隔ロック、遠隔消去を使えるようにし、紛失したときはためらわず会社に連絡します。ソフトウェアの更新は、脆弱性をふさぐ最も基本的な対策なので、後回しにせず適用します。
バックアップは、ランサムウェアや機器の故障、誤削除から立ち直るための最後のとりでです。重要なデータは定期的に別の場所へ複製し、複製先を常時つないだままにしないこと(つないだままだと暗号化の被害が及ぶ)、そして復元できることをときどき試すことが大切です。最後に、対策と業務効率のバランスについて。厳しすぎるルールは現場で守られず、抜け道(私物クラウドの利用、パスワードの共有)を生んで、かえって危険になります。ルールを作る側は、なぜ必要かを説明し、現場が実行できる形にし、無理があるという声が上がったら見直します。おかしいと感じたときにすぐ相談できる窓口を周知しておくことが、結局は最も効く対策です。
迷わず相談する場面の一覧(社内の窓口の連絡先は、すぐ見える場所に控えておく)
こんなときは、自分で解決しようとせずにすぐ相談する 1. あやしいメールを開いた、添付ファイルを実行した、リンク先でIDを入力した 2. PC、スマートフォン、USBメモリ、書類を紛失した、盗まれた 3. 見覚えのない警告や画面が出た、PCが急に遅くなった、勝手に再起動する 4. 送るべきでない相手にメールやファイルを送ってしまった 5. 社内の誰かから、電話やチャットでパスワードを聞かれた 6. クラウドの共有範囲を全体公開にしてしまったかもしれない ※ 報告が早いほど被害は小さくなる。隠すことが最大の損害につながる
| 場面 | やること | なぜ |
|---|---|---|
| パスワード | 長いパスフレーズにし、サービスごとに変える | 使い回すと一つの漏えいが他のサービスに連鎖する |
| ログイン | 使えるなら多要素認証を有効にする | パスワードが漏れても不正ログインを防ぎやすい |
| メール | リンクを押さず、ブックマークや公式アプリから確認する | 本物そっくりの偽サイトに誘導されるのを防ぐ |
| 外出先 | 公衆Wi-FiではVPNかテザリングを使う | 暗号化されていない通信や偽のアクセスポイントの被害を避ける |
| 離席時 | 画面をロックし、机上に書類を残さない | のぞき見と持去りを防ぐ |
| スマートフォン | 画面ロック、公式ストアからの導入、権限の確認 | 紛失時の情報流出と不正アプリを防ぐ |
| 更新 | OSとアプリの更新をすぐに適用する | 既知の脆弱性を悪用する攻撃を防ぐ |
| バックアップ | 定期的に別の場所へ複製し、復元を試す | ランサムウェアや故障、誤削除から立ち直る |
| 困ったとき | 自分で判断せず、社内の窓口へすぐ相談する | 初動が早いほど被害は小さくなる |
- パスフレーズ
- 複数の単語をつないだ長いパスワード。記号を無理に混ぜた短いものより、長く覚えやすいものにするほうが解読されにくく、使い回さないこととあわせて効果が大きい。
- パスワードの使い回し
- 複数のサービスで同じIDとパスワードを使うこと。どこか一つから漏れると、それを他のサービスで試す攻撃により連鎖的に被害が広がる。管理ソフトの利用や多要素認証で回避する。
- 偽のアクセスポイント
- 正規の公衆Wi-Fiに似せた名前で設置され、接続した端末の通信を盗み見る不正なアクセスポイント。業務ではVPNやテザリングを使い、機密情報のやり取りを避ける。
- 野良アプリ
- 公式のアプリストア以外から入手する、提供元や安全性が確認できないアプリ。不正な権限要求や情報の持出しの恐れがあるため、業務端末にも私物端末にも入れない。
- セキュリティと利便性のバランス
- 厳しすぎる規則は守られず抜け道を生み、緩すぎる規則は事故を招くという関係。理由を説明し、現場が実行できる手順にし、実態に合わせて見直すことが必要になる。
例題 取引先を名乗るメールに『請求書の確認をお願いします』とあり、リンクが付いていた。どうするか。
リンクは押さず、メールに書かれた連絡先も使わない。日ごろ使っている電話番号やアドレスなど、別の経路で取引先に確認する。すでに押してIDを入力してしまった場合は、そのパスワードを直ちに変更し、社内の窓口に報告する。恥ずかしがって黙ることが最も被害を大きくする。
例題 『規程が厳しすぎて仕事が回らない』と現場から声が上がった。リーダーとしてどうするか。
無視すると、私物クラウドの利用やパスワードの共有といった抜け道が生まれ、かえって危険になる。まず実際の業務の流れを聞き、リスクを保ったまま手順を簡単にできないかを検討し、必要なら規程そのものを見直す。守れないルールは守られないという前提で設計する。
例題 スマートフォンに入れたい便利なアプリが、連絡先と位置情報の権限を求めてきた。
そのアプリの機能に照らして必要な権限かを考える。たとえば単純な電卓や写真加工アプリが連絡先を求めるのは不自然で、入れない判断が妥当である。公式ストア以外から入手したアプリは使わず、業務端末では会社が許可したアプリだけを使う。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類1:技術要素 中分類1:セキュリティ 小分類4 情報セキュリティ対策(情報漏えい対策・利用者の対策・啓発活動)/IPA 情報セキュリティ10大脅威 解説資料
情報セキュリティ関連法規
サイバー犯罪と不正アクセス
「その行為はどの法律で禁じられているか」を取り違えずに答えられるようになる。
情報セキュリティの法規で最も点を落としやすいのは、行為と法律の対応を取り違えることです。他人のIDとパスワードを無断で使ってログインするのは不正アクセス禁止法、ウイルスを作ったり配ったりするのは刑法、会社の顧客名簿を持ち出して他社で使うのは不正競争防止法、というように、まず「入口」を正しく選べることが出発点になります。
不正アクセス禁止法(不正アクセス行為の禁止等に関する法律)が禁じているのは、大きく分けて次の行為です。(1) 他人の識別符号(ID・パスワードなど)を無断で入力してネットワーク経由でコンピュータを使える状態にする行為、(2) セキュリティホールを突いて同じ状態を作る行為、(3) 他人の識別符号を不正に取得する行為、(4) 他人の識別符号を、業務その他正当な理由なく第三者に提供する助長行為、(5) 他人の識別符号を不正に保管する行為、(6) 管理者になりすまして識別符号の入力を求めるフィッシング行為です。ここで重要なのは、この法律が「電気通信回線を通じて」=ネットワーク経由の行為を対象にしていることです。ネットワークにつながっていないパソコンを、その場で直接操作して他人のIDでログインしても、この法律の不正アクセス行為には当たりません。
また、この法律は「アクセスした」時点で成立し、情報を実際に見たか、盗んだか、壊したかは問いません。逆に、正しく自分のIDでログインしたあとで権限外のファイルを見た場合は、不正アクセス行為ではなく社内規程違反や別の罪の問題になります。アクセス管理者(サーバの管理者)にも、識別符号の適正な管理という努力義務が課されています。
ウイルスそのものを扱う行為は刑法の不正指令電磁的記録に関する罪(いわゆるウイルス罪)です。人の意図に反する動作をさせる不正な指令を与える電磁的記録について、作成・提供・供用(実際に実行させる状態に置くこと)・取得・保管が処罰されます。このほか刑法には、うそのデータを入力して不法に利益を得る電子計算機使用詐欺罪、コンピュータやデータを壊して業務を妨害する電子計算機損壊等業務妨害罪、権利義務に関する電磁的記録を偽って作る私電磁的記録不正作出罪などがあり、いずれも「刑法」である点が問われます。
国全体の枠組みを定めるのがサイバーセキュリティ基本法です。国と地方公共団体には責務を、重要社会基盤事業者(電気・ガス・金融・医療・鉄道など)やサイバー関連事業者、教育研究機関には自主的な取組みの努力を求め、内閣にサイバーセキュリティ戦略本部を置いて政府の司令塔としています。実務の中核を担ってきた内閣サイバーセキュリティセンター(NISC)は、2025年7月1日に内閣官房の国家サイバー統括室(NCO)へ改組されました。基本法は「体制と責務を定める法律」であって、個々の犯罪を処罰する法律ではないことに注意してください。
企業の秘密を守るのが不正競争防止法です。保護される営業秘密は、秘密管理性(秘密として管理されている)・有用性(事業活動に有用な技術上または営業上の情報である)・非公知性(公然と知られていない)の3要件をすべて満たすものだけです。3つのうち1つでも欠ければ営業秘密ではなく、たとえば誰でも閲覧できる共有フォルダに置いたままの名簿は秘密管理性を欠きます。さらに、会員企業などに業として提供することを前提に、電磁的方法で相当量蓄積・管理されたデータは、営業秘密に当たらなくても限定提供データとして保護されます(定義から営業秘密は除かれます)。
| 区分 | 法律 | 禁止・処罰される主な行為 | 取り違えやすい点 |
|---|---|---|---|
| なりすまし | 不正アクセス禁止法 | 他人のID・パスワードでのログイン、セキュリティホール攻撃、識別符号の不正取得・保管・助長行為、フィッシング行為 | ネットワーク経由が要件。直接操作は対象外 |
| ウイルス | 刑法(不正指令電磁的記録に関する罪) | ウイルスの作成・提供・供用・取得・保管 | 不正アクセス禁止法ではない |
| 不正な利得 | 刑法(電子計算機使用詐欺罪) | 虚偽の情報や不正な指令を与えて不法の利益を得る行為 | 詐欺の一種であり刑法の罪 |
| 業務妨害 | 刑法(電子計算機損壊等業務妨害罪) | コンピュータやデータを壊す、不正な指令を与えるなどして業務を妨害する行為 | DoS攻撃などが該当しうる |
| 文書の偽り | 刑法(私電磁的記録不正作出罪) | 権利義務に関する電磁的記録を不正に作る行為 | 紙の文書の偽造とは別の罪名 |
| 企業秘密 | 不正競争防止法 | 営業秘密の不正取得・使用・開示、限定提供データの不正取得等 | 3要件を満たさない情報は営業秘密ではない |
| 国の体制 | サイバーセキュリティ基本法 | (罰則ではなく)国・地方公共団体・重要社会基盤事業者などの責務と努力を定める | 処罰の根拠にはならない |
- 不正アクセス行為
- 他人の識別符号を無断で入力する、またはセキュリティホールを突くことにより、電気通信回線を通じてアクセス制御機能のあるコンピュータを利用できる状態にする行為。ネットワークを経由しない直接操作は含まれない。
- 識別符号
- 利用権者を識別するためにアクセス管理者が定めた符号。IDとパスワードの組合せのほか、指紋や声紋などの身体的特徴を変換した符号、署名を変換した符号が含まれる。
- 助長行為
- 業務その他正当な理由がないのに、他人の識別符号をその利用権者や管理者以外の第三者に提供する行為。実際に不正アクセスが行われなくても、提供した時点で不正アクセス禁止法の違反になる。
- フィッシング行為
- アクセス管理者になりすまして、利用権者に識別符号の入力を求める偽サイトを公開したり、そのようなメールを送ったりする行為。不正アクセス禁止法で識別符号の入力を不正に要求する行為として禁止されている。
- 不正指令電磁的記録に関する罪
- 刑法に定めるいわゆるウイルス罪。人の意図に反する動作をさせる不正な指令を与える電磁的記録の作成・提供・供用・取得・保管を処罰する。感染させる前の作成や保管の段階でも成立しうる。
- 電子計算機使用詐欺罪
- 刑法の罪。虚偽の情報や不正な指令をコンピュータに与えて、財産権の得喪や変更に係る不実の電磁的記録を作り、不法の利益を得る行為を処罰する。他人のクレジットカード情報での不正決済などが典型。
- 電子計算機損壊等業務妨害罪
- 刑法の罪。業務に使うコンピュータやデータを壊す、虚偽の情報や不正な指令を与えるなどして、コンピュータに使用目的に沿う動作をさせず業務を妨害する行為を処罰する。
- サイバーセキュリティ基本法
- 国のサイバーセキュリティ施策の基本理念と、国・地方公共団体・重要社会基盤事業者などの責務や努力を定める法律。内閣にサイバーセキュリティ戦略本部を置く。個別の犯罪を処罰する規定はない。
- 営業秘密
- 不正競争防止法で保護される情報。秘密管理性・有用性・非公知性の3要件をすべて満たす必要があり、1つでも欠けると営業秘密として保護されない。
- 限定提供データ
- 業として特定の者に提供する情報として、電磁的方法により相当量蓄積され管理されている技術上または営業上の情報(営業秘密を除く)。会員企業などに提供されるデータの流通を守るために不正競争防止法で保護される。秘密として管理されていても、公然と知られていて営業秘密に当たらないものは、この類型で保護されうる。
例題 同僚から「急ぎで資料が要る」と頼まれ、自分のIDとパスワードを教えた。同僚はそれで社内システムにログインした。誰にどの問題があるか。
パスワードを教えた側は、正当な理由なく他人の識別符号を第三者に提供したことになり、不正アクセス禁止法の助長行為に当たりうる。ログインした同僚は不正アクセス行為に当たりうる。「悪意がなかった」「業務のためだった」は理由にならず、正規の権限申請で対応すべき場面である。
例題 退職予定の社員が、誰でも読める共有フォルダに置かれていた顧客名簿をコピーして持ち出した。不正競争防止法の営業秘密の侵害として争えるか。
難しい。営業秘密には秘密管理性が必要で、アクセス制限も「マル秘」表示もない状態では、会社が秘密として管理していたとは認められにくい。有用性と非公知性を満たしていても、3要件のうち1つを欠けば営業秘密にはならない。日ごろからアクセス権の限定と表示を行っておくことが法的保護の前提になる。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類2:企業と法務 中分類2:法務/不正アクセス行為の禁止等に関する法律・刑法(不正指令電磁的記録に関する罪)・不正競争防止法・サイバーセキュリティ基本法
個人情報を守る法律
個人情報・個人データ・要配慮個人情報・仮名加工情報・匿名加工情報の違いと、第三者提供のルールを整理する。
個人情報保護法でいう個人情報とは、生存する個人に関する情報で、氏名や生年月日などにより特定の個人を識別できるもの、または個人識別符号を含むものです。他の情報と容易に照合でき、それによって個人を識別できるものも含まれます。死者の情報や、法人そのものの情報は個人情報ではありません。
個人識別符号は、指紋・掌紋・虹彩・声紋・顔・歩行の態様・DNAといった身体的特徴を変換した符号と、マイナンバー・旅券番号・基礎年金番号・運転免許証番号・住民票コードなど公的な番号を指します。これ単体で個人情報になります。
個人情報は、扱われ方によって呼び名が変わります。個人情報を検索できるように体系的に整理したものが個人情報データベース等で、それを構成する一つ一つが個人データです。安全管理措置や第三者提供の制限といった義務の多くは、この個人データに対してかかります。さらに、事業者が開示・訂正・利用停止などに応じる権限をもつ個人データが保有個人データで、本人からの開示等の請求はこれに対して行われます。
要配慮個人情報は、本人に不当な差別や偏見が生じないよう特に配慮を要する情報です。人種、信条、社会的身分、病歴、犯罪の経歴、犯罪により害を被った事実などが該当し、政令で、障害があること、健康診断等の結果、その結果に基づく医師等による指導・診療・調剤が行われたこと、被疑者・被告人として刑事事件に関する手続が行われたこと、少年として保護事件に関する手続が行われたことが加わります。取得には原則としてあらかじめ本人の同意が必要で、後述のオプトアウトによる第三者提供は認められません。一方、メールアドレス、電話番号、国籍、本籍地、収入や資産の情報は要配慮個人情報ではありません。
第三者提供は原則として、あらかじめ本人の同意が必要です。例外として、法令に基づく場合、人の生命・身体・財産の保護に必要で本人の同意を得ることが困難な場合、公衆衛生の向上や児童の健全な育成に特に必要な場合、国等への協力が必要な場合は同意なく提供できます。オプトアウトは、本人の求めがあれば提供を停止することとしたうえで、必要な事項を本人に通知するか本人が容易に知り得る状態に置き、個人情報保護委員会に届け出れば、同意なく第三者提供できる仕組みです。ただし要配慮個人情報、不正に取得した個人データ、オプトアウトで受け取った個人データは、オプトアウトの対象外です。
「第三者ではない」とされる形もあります。利用目的の達成に必要な範囲での委託、合併等の事業承継、そして共同利用です。共同利用は、共同利用する旨、対象となる個人データの項目、共同利用する者の範囲、利用目的、管理について責任を有する者の氏名等をあらかじめ本人に通知するか容易に知り得る状態に置く必要があります。委員会への届出は不要である点がオプトアウトと違います。なお委託した場合は、委託元に委託先を監督する義務が残ります。外国にある第三者への提供は、原則として本人の同意が必要で、その際に移転先国の制度や体制についての情報を本人に提供しなければなりません。
仮名加工情報と匿名加工情報は名前が似ていますが目的が違います。仮名加工情報は、他の情報と照合しない限り特定の個人を識別できないように加工したもので、社内での分析に使うことを想定しています。元の情報と結びつける情報(削除情報等)は残るため、原則として第三者への提供はできません(委託・事業承継・共同利用は例外)。匿名加工情報は、特定の個人を識別できず、かつ元の個人情報を復元できないように加工したもので、本人の同意なく第三者に提供できます。提供するときは、提供する情報の項目と提供方法をあらかじめ公表し、相手方に匿名加工情報である旨を明示します。どちらも、本人を識別する目的で他の情報と照合することは禁止されています。
漏えい等が起きたとき、要配慮個人情報が含まれる場合、財産的被害が生じるおそれがある場合、不正の目的によるおそれがある場合、本人の数が1,000人を超える場合は、個人情報保護委員会への報告と本人への通知が義務となります。個人情報保護委員会は内閣府の外局として置かれる独立性の高い第三者機関で、報告徴収・立入検査・指導助言・勧告・命令を行います。
関連する枠組みとして、個人情報保護マネジメントシステムの要求事項を定めたJIS Q 15001と、それに基づいて第三者が審査するプライバシーマーク制度があります。EUのGDPR(一般データ保護規則)は2018年に適用が始まり、EEA域外への個人データ移転を制限し、データポータビリティの権利などを定めています。マイナンバー法(番号法)は、個人番号の利用範囲を社会保障・税・災害対策の3分野に限定し、個人情報保護法より厳しい取扱いを求めています。
| 区分 | 呼び名 | 中身 | 第三者提供 | 本人の関与 |
|---|---|---|---|---|
| 基本 | 個人情報 | 生存する個人を識別できる情報、または個人識別符号を含む情報 | 個人データとしての規律による | 利用目的の通知・公表を受ける |
| 基本 | 個人データ | 個人情報データベース等を構成する個人情報 | 原則として本人の同意が必要 | 安全管理措置の対象 |
| 基本 | 保有個人データ | 事業者が開示・訂正・利用停止等を行える個人データ | 個人データと同じ | 開示・訂正・利用停止を請求できる |
| 特別 | 要配慮個人情報 | 人種・信条・社会的身分・病歴・犯罪の経歴など | 本人の同意が必要。オプトアウトは不可 | 取得にも原則として同意が必要 |
| 加工 | 仮名加工情報 | 他の情報と照合しない限り個人を識別できないように加工 | 原則不可(委託・事業承継・共同利用は可) | 開示・利用停止の請求の対象外 |
| 加工 | 匿名加工情報 | 個人を識別できず、かつ復元もできないように加工 | 本人の同意なく可能(項目の公表と相手方への明示が必要) | 本人を識別する照合は禁止 |
- 個人情報
- 生存する個人に関する情報で、特定の個人を識別できるもの、または個人識別符号を含むもの。他の情報と容易に照合して識別できるものも含む。死者の情報や法人の情報は含まれない。
- 個人データ
- 個人情報データベース等を構成する個人情報。安全管理措置、従業者・委託先の監督、第三者提供の制限といった義務は、この個人データを対象としてかかる。
- 保有個人データ
- 個人情報取扱事業者が、開示・内容の訂正・追加・削除・利用の停止・消去・第三者提供の停止を行う権限をもつ個人データ。本人からの開示等の請求はこれに対して行われる。
- 個人識別符号
- 指紋・虹彩・声紋・顔・DNAなど身体的特徴を変換した符号や、マイナンバー・旅券番号・運転免許証番号などの公的な番号。単体で個人情報となる。
- 要配慮個人情報
- 人種、信条、社会的身分、病歴、犯罪の経歴、犯罪により害を被った事実など、不当な差別や偏見が生じないよう特に配慮を要する個人情報。取得に原則本人同意が必要で、オプトアウトによる第三者提供はできない。
- 仮名加工情報
- 他の情報と照合しない限り特定の個人を識別できないように加工した個人に関する情報。社内での分析利用を想定し、委託・事業承継・共同利用を除いて第三者提供はできない。
- 匿名加工情報
- 特定の個人を識別できず、かつ元の個人情報を復元できないように加工した情報。本人の同意なく第三者提供できるが、情報の項目と提供方法の公表、相手方への明示、識別行為の禁止といった義務が伴う。
- オプトアウト
- 本人の求めがあれば第三者提供を停止することとし、所定事項を本人に通知するか容易に知り得る状態に置いたうえで個人情報保護委員会に届け出ることで、同意なく第三者提供を行える仕組み。要配慮個人情報などは対象外。
- 共同利用
- あらかじめ共同利用する旨・項目・共同利用者の範囲・利用目的・管理責任者の氏名等を本人に通知するか容易に知り得る状態に置くことで、第三者提供に当たらないとされる形態。委員会への届出は不要。
- 個人情報保護委員会
- 個人情報とマイナンバーの適正な取扱いを確保するために置かれた、内閣府の外局である独立性の高い第三者機関。報告徴収、立入検査、指導・助言、勧告、命令を行う。
- プライバシーマーク制度
- JIS Q 15001(個人情報保護マネジメントシステム—要求事項)に適合して個人情報を適切に取り扱う体制を整えている事業者を、第三者が審査して認定し、マークの使用を認める制度。
例題 自社の会員データから氏名と住所を削除し、会員IDだけを残して社内のマーケティング部門で分析したい。仮名加工情報と匿名加工情報のどちらとして扱うのが適切か。
社内での分析利用なら仮名加工情報が適する。元データと結びつける情報を残せるため分析の精度を保てるが、そのぶん第三者への提供は原則できず、本人への連絡や本人を識別する照合も禁止される。外部の企業にデータを渡して活用したいのであれば、復元できないところまで加工した匿名加工情報にする必要がある。
例題 健康診断の結果を含む従業員名簿を、グループ会社と共有したいと相談された。どう答えるか。
健康診断の結果は要配慮個人情報に当たるため、オプトアウトによる提供はできない。あらかじめ本人の同意を得るか、共同利用の要件(共同利用する旨・項目・範囲・利用目的・管理責任者を本人に通知するか容易に知り得る状態に置く)を満たして共同利用の枠組みを整える必要がある。「グループ会社だから第三者ではない」という説明は誤りである。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類2:企業と法務 中分類2:法務/個人情報の保護に関する法律・個人情報保護委員会ガイドライン・JIS Q 15001・GDPR・番号法
通信・情報流通に関する法律
ネット上の書込みへの対応、広告メール、電子署名、著作物の扱いなど、情報の流通に関わる法律をまとめて押さえる。
インターネット上の権利侵害への対応を定めていたプロバイダ責任制限法は、2024年の法改正により情報流通プラットフォーム対処法へと名称が変わり、2025年(令和7年)4月1日に施行されました。従来からのプロバイダの損害賠償責任の制限と発信者情報開示請求の仕組みは引き継ぎつつ、大規模なプラットフォーム事業者(総務大臣が指定する大規模特定電気通信役務提供者)に対する義務が新たに加えられたのが改正の中心です。
大規模特定電気通信役務提供者に課される主な義務は、侵害情報の削除の申出を受け付ける方法を定めて公表すること、専門的な知識経験をもつ侵害情報調査専門員を選任すること、申出に対して調査を行い一定の期間内に結果を申出者へ通知すること、どのような場合に削除するかという基準を定めて公表すること、そして申出の受付や対応の状況を年1回公表することです。書込みの削除そのものを国が命じる制度ではなく、事業者の対応を迅速化・透明化させる制度である点を押さえてください。
電気通信事業法は、通信の秘密を守ることを事業者に義務づけ、検閲を禁じています。通信の内容だけでなく、誰と誰がいつ通信したかという情報も通信の秘密に含まれます。社内のネットワークを監視する場合でも、通信事業者に該当する場面ではこの点への配慮が必要です。
広告や宣伝を目的とする電子メールを規制するのが特定電子メール法です。原則はオプトインで、あらかじめ送信に同意した人にしか広告宣伝メールを送れません。同意を得た記録は保存しなければならず、メールには送信者の氏名または名称と、受信拒否の通知を受けるための連絡先(メールアドレスまたはURL)を表示する必要があります。送信者情報を偽って送信することも禁止されています。取引関係にある相手や、名刺などで自分のメールアドレスを通知してきた相手には、同意がなくても送れる例外があります。
電子署名法は、本人だけが行える一定の要件を満たす電子署名が付された電磁的記録は、真正に成立したものと推定されると定めています。これにより電子文書に紙の押印文書と同様の証拠力が与えられます。
著作権法では、プログラムは著作物として保護されますが、その背後にあるアルゴリズム(解法)やプログラム言語、通信規約(プロトコル)は保護されません。データベースは、情報の選択または体系的な構成に創作性があれば著作物として保護されます。保護期間は原則として著作者の死後70年、法人などの団体名義の著作物は公表後70年です。私的使用のための複製は認められますが、違法にアップロードされたものと知りながらダウンロードする場合や、コピープロテクトを回避して複製する場合は認められません。引用は、公表された著作物であること、公正な慣行に合致すること、正当な範囲内であること、引用部分が明瞭に区別され本文が主で引用が従であること、出所を明示することが条件です。
情報解析のように、著作物に表現された思想または感情を自分や他人が享受することを目的としない利用は、著作権法第30条の4により、必要と認められる限度で著作権者の許諾なく行えます。AIの学習用にWeb上の著作物を収集して解析する行為も、原則としてこの規定の範囲で行えると整理されています。ただし、著作権者の利益を不当に害することとなる場合は除かれます。また、AIが生成したものが既存の著作物と類似し、それに依拠していると認められる場合は、生成・利用の段階で著作権侵害になりえます。プログラムのリバースエンジニアリング(調査解析を目的とするプログラムの利用)も、機能を享受することに向けられた利用ではないとして、文化庁はこの規定に該当すると整理しています。
帳簿や書類の電子化に関わるのが電子帳簿保存法とe-文書法です。電子帳簿保存法は国税関係の帳簿書類を電子データで保存するための要件を定め、電子取引でやり取りしたデータは電子データのまま保存することを求めています。e-文書法は、法令で保存が義務づけられた文書を広く電子的に保存できるようにする法律で、見読性・完全性などの要件が求められます。資金決済法は、前払式支払手段、資金移動業、暗号資産の交換業などについて登録制や利用者保護のルールを定めています。
| 区分 | 法律 | 守る対象・要点 |
|---|---|---|
| ネット上の権利侵害 | 情報流通プラットフォーム対処法(旧プロバイダ責任制限法・2025年4月1日施行) | プロバイダの責任の制限、発信者情報開示、大規模事業者の削除申出対応・基準公表・年1回の状況公表 |
| 通信 | 電気通信事業法 | 通信の秘密の保護、検閲の禁止。通信の内容だけでなく通信の存在や相手も対象 |
| メール | 特定電子メール法 | 広告宣伝メールはオプトインが原則。送信者情報の表示、受信拒否の連絡先の表示、送信者情報を偽った送信の禁止 |
| 電子文書 | 電子署名法 | 一定の要件を満たす電子署名がある電磁的記録は真正に成立したものと推定される |
| 著作物 | 著作権法 | プログラム・データベースの保護、私的複製、引用、原則として著作者の死後70年、情報解析のための利用 |
| 帳簿 | 電子帳簿保存法 | 国税関係帳簿書類の電子保存の要件。電子取引データは電子のまま保存 |
| 文書一般 | e-文書法 | 法令で保存が義務づけられた書面の電磁的記録による保存を広く容認 |
| 決済 | 資金決済法 | 前払式支払手段、資金移動業、暗号資産交換業の登録制と利用者保護 |
- 情報流通プラットフォーム対処法
- 旧プロバイダ責任制限法。2024年の改正で名称が変わり2025年4月1日に施行された。プロバイダの損害賠償責任の制限と発信者情報開示に加え、大規模なプラットフォーム事業者に削除申出への対応や基準の公表を義務づける。
- 発信者情報開示請求
- 権利を侵害する書込みをされた者が、侵害情報の発信者を特定するために、プロバイダなどに対して発信者の氏名・住所・IPアドレスなどの開示を求める手続。裁判手続によって行う仕組みが整備されている。
- 通信の秘密
- 電気通信事業法などで保護される、通信の内容および通信当事者・日時などの構成要素を他に知られない権利。電気通信事業者には通信の秘密を守る義務があり、検閲は禁止されている。
- オプトイン(特定電子メール法)
- あらかじめ同意した相手にだけ広告宣伝メールを送ってよいという原則。同意を得た記録の保存、送信者の氏名または名称および受信拒否の連絡先の表示が義務づけられている。
- 電子署名法
- 本人だけが行うことができる一定の要件を満たす電子署名が行われた電磁的記録について、真正に成立したものと推定すると定めた法律。電子文書に紙の押印と同様の証拠力を与える。
- 著作権法の保護対象外
- プログラムは著作物として保護されるが、その基礎となるアルゴリズム(解法)、プログラム言語、通信規約(プロトコル)は保護されない。アイディアそのものは保護されず、表現が保護される。
- 引用の要件
- 公表された著作物であること、公正な慣行に合致すること、報道・批評・研究などの目的上正当な範囲内であること、引用部分が明瞭に区別され本文が主・引用が従であること、出所を明示すること。
- 情報解析のための利用
- 著作物に表現された思想または感情を享受することを目的としない利用は、著作権法第30条の4により必要な限度で許諾なく行える。AIの学習のための解析も原則この範囲だが、著作権者の利益を不当に害する場合は除かれる。
- 電子帳簿保存法
- 国税関係の帳簿書類を電子データで保存するための要件を定めた法律。電子取引でやり取りしたデータは、紙に出力するのではなく電子データのまま保存することが求められる。
- e-文書法
- 民間事業者等が法令で保存を義務づけられた書面を、電磁的記録で保存・作成・縦覧等することを一般的に認める法律。見読性や完全性などの要件を満たす必要がある。
例題 自社のSNS公式アカウントに、社員個人を名指しした誹謗中傷が繰り返し投稿されている。まず何を検討するか。
情報流通プラットフォーム対処法に基づき、そのプラットフォーム事業者が公表している削除申出の受付方法に従って申出を行う。大規模特定電気通信役務提供者であれば、調査のうえ一定期間内に判断結果が通知される。発信者の特定が必要なら発信者情報開示請求を検討する。自分で相手のアカウントに侵入して調べるといった対応は、不正アクセス禁止法違反になりうる。
例題 過去に問合せをくれた顧客のメールアドレス一覧に、新商品の案内メールを一斉送信したいと言われた。確認すべきことは何か。
特定電子メール法はオプトインが原則なので、広告宣伝メールの送信について同意を得ているか、その記録が残っているかを確認する。取引関係にある相手や名刺でアドレスを通知してきた相手には例外があるが、単に問合せがあっただけでは同意とは限らない。加えて、送信者の名称と受信拒否の連絡先をメール本文に表示する必要がある。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類2:企業と法務 中分類2:法務/情報流通プラットフォーム対処法(総務省)・電気通信事業法・特定電子メール法・電子署名法・著作権法・電子帳簿保存法・e-文書法
働くうえでのルールと標準
契約形態ごとの指揮命令と情報の取扱い責任、そしてセキュリティで使われる標準やガイドラインを押さえる。
労働基準法は労働条件の最低基準を定める法律で、労働時間、休日、賃金、労働条件の明示などを規定します。就業規則は、常時10人以上の労働者を使用する事業場では作成と行政官庁への届出が必要です。情報セキュリティ規程に違反した従業員を懲戒するには、その根拠が就業規則に定められ、周知されていることが前提になります。規程だけを作って就業規則と結びつけていないと、実効性を欠くことになります。
外部の人に仕事をしてもらう形には、大きく請負・準委任・労働者派遣があります。請負は仕事の完成を目的とする契約で、注文者は請負事業者の労働者に直接指揮命令できません。準委任は事務の処理を委託する契約で、善良な管理者の注意をもって処理する義務を負いますが、仕事の完成義務は原則ありません。こちらも委託者が受託者の労働者を直接指揮命令することはできません。労働者派遣は、派遣元と労働者が雇用関係を結び、派遣先が指揮命令を行う形です。指揮命令をするのが誰かが、この3つを分ける決定的な違いになります。
請負や準委任の契約でありながら、実態として発注者が相手の労働者に直接指示を出している状態を偽装請負といい、労働者派遣法などに違反します。開発の現場で、常駐している協力会社の社員に自社の社員が直接作業指示を出してしまう、というのがよくある形です。指示は必ず相手方の責任者を通す運用にすることが必要です。
業務委託にあたっては秘密保持契約(NDA)を結びます。秘密情報の範囲、目的外での使用の禁止、複製や再委託の可否、契約終了後の返還または廃棄、有効期間(契約終了後も一定期間継続させることが多い)を定めます。委託した場合でも、個人データを預けたのであれば委託元には委託先を監督する義務が残る点は、契約書があるかどうかとは別に押さえておく必要があります。
下請取引の公正さを確保してきた下請法は、2026年(令和8年)1月1日に中小受託取引適正化法(略称・取適法)へと名称が変わりました。あわせて、「親事業者」は「委託事業者」、「下請事業者」は「中小受託事業者」と呼び方が改められ、資本金による判断基準に加えて常時使用する従業員数による基準が追加され、特定運送委託が対象取引に加えられ、手形による支払が禁止され、コスト上昇時に協議に応じないまま一方的に代金を決めることが禁止されました。
不正を早い段階で見つけるための仕組みが内部通報制度です。公益通報者保護法は、通報したことを理由とする解雇その他の不利益な取扱いを禁じ、常時使用する労働者が301人以上の事業者に対して内部公益通報に対応する体制の整備を義務づけています。通報を受け付ける担当者は公益通報対応業務従事者として指定され、通報者を特定させる情報について守秘義務を負います。
標準を作る組織も整理しておきます。ISO(国際標準化機構)とIEC(国際電気標準会議)は国際規格、JIS(日本産業規格)は国内の規格で、ISO/IEC規格を国内規格として取り入れたものにはJIS Qなどの記号が付きます。IETFはインターネットの技術仕様をRFCとして公開し、W3CはWebの技術仕様を策定し、NIST(米国国立標準技術研究所)はSP 800シリーズやサイバーセキュリティフレームワークを公開しています。
情報セキュリティの中核となるのがJIS Q 27000シリーズです。JIS Q 27000は用語と概要、JIS Q 27001はISMSの要求事項で認証の基準となるもの、JIS Q 27002は管理策の実践の規範です。認証を受けるのはJIS Q 27001に対してであり、27002は実装のための手引という位置づけです。個人情報の分野ではJIS Q 15001が対応します。
脆弱性を共通の言葉で扱うための仕組みもあります。CVEは個別の脆弱性に付けられる共通の識別子、CVSSは脆弱性の深刻度を同じ尺度で評価するための共通評価システムで、0.0から10.0の値で表します。国内で広く使われているCVSS v3では、基本評価基準・現状評価基準・環境評価基準の3つで評価します。CWEは脆弱性の種類を分類したもので、JVNはJPCERTコーディネーションセンターとIPAが共同で運営する日本の脆弱性対策情報ポータルサイトです。
経営層向けの指針としては、経済産業省とIPAによるサイバーセキュリティ経営ガイドラインがあり、経営者が認識すべき3原則と、経営者がCISOなどの担当幹部に指示すべき重要10項目を示しています。中小企業向けにはIPAの中小企業の情報セキュリティ対策ガイドラインがあり、まず取り組むべき情報セキュリティ5か条や、自己宣言を行うSECURITY ACTIONの仕組みが用意されています。
| 観点 | 請負 | 準委任 | 労働者派遣 |
|---|---|---|---|
| 契約の目的 | 仕事の完成 | 事務の処理(完成義務は原則なし) | 労働者を派遣して労務を提供させること |
| 雇用関係 | 受託側の会社と労働者 | 受託側の会社と労働者 | 派遣元と労働者 |
| 指揮命令をする者 | 受託側の会社(発注者は直接指示できない) | 受託側の会社(委託者は直接指示できない) | 派遣先 |
| 対価の考え方 | 成果物に対して支払う | 実施した業務や工数に対して支払う | 派遣元に派遣料金を支払う |
| 情報の取扱い責任 | 契約とNDAで定める。個人データの委託なら委託元に監督義務 | 契約とNDAで定める。個人データの委託なら委託元に監督義務 | 派遣先が自社の規程を適用し、派遣労働者に守らせる |
| 違反しやすい形 | 発注者が直接指示すると偽装請負 | 委託者が直接指示すると偽装請負 | 受け入れた労働者を他社へ出すと二重派遣 |
- 偽装請負
- 請負や準委任の契約でありながら、実態として発注者が受託側の労働者に直接指揮命令している状態。労働者派遣法などに違反する。指示は相手方の責任者を通す運用にすることで防ぐ。
- 労働者派遣
- 派遣元と労働者が雇用関係を結び、派遣先が労働者に指揮命令を行う形態。派遣先事業所単位・派遣労働者個人単位で期間の制限があり、派遣労働者を特定する目的の事前面接は原則禁止されている。
- 請負契約
- 仕事の完成を目的とする契約。注文者は請負事業者の労働者に直接指揮命令できず、完成した成果物に対して対価を支払う。瑕疵(契約不適合)に対する責任を請負人が負う。
- 準委任契約
- 事務の処理を委託する契約。受託者は善良な管理者の注意をもって事務を処理する義務を負うが、仕事の完成義務は原則としてない。委託者が受託者の労働者に直接指揮命令することはできない。
- 秘密保持契約(NDA)
- 取引の過程で知った情報を外部に漏らさないことを約束する契約。秘密情報の範囲、目的外使用の禁止、再委託や複製の可否、契約終了後の返還・廃棄、有効期間を定める。
- 中小受託取引適正化法
- 下請法から名称が変わった法律(略称・取適法、2026年1月1日施行)。親事業者は委託事業者、下請事業者は中小受託事業者と呼び名が改められ、従業員数基準の追加、特定運送委託の対象化、手形払の禁止などが行われた。
- 公益通報者保護法
- 内部通報をしたことを理由とする解雇その他の不利益な取扱いを禁じる法律。常時使用する労働者が301人以上の事業者には内部公益通報に対応する体制の整備が義務づけられ、担当者は通報者を特定させる情報について守秘義務を負う。
- JIS Q 27001とJIS Q 27002
- 27001はISMSの要求事項を定める規格で、認証審査の基準となる。27002は情報セキュリティ管理策の実践の規範であり、27001を実装するための手引という位置づけで、これ自体は認証の基準ではない。
- CVSS
- 脆弱性の深刻度を同じ尺度で評価するための共通評価システム。0.0から10.0の数値で深刻度を表す。CVSS v3では基本評価基準・現状評価基準・環境評価基準の3つで評価する。個別の脆弱性を識別する番号ではない。
- CVEとJVN
- CVEは個別の脆弱性に付けられる共通の識別子。JVNはJPCERTコーディネーションセンターとIPAが共同運営する日本の脆弱性対策情報ポータルサイトで、対策情報を提供する。
- サイバーセキュリティ経営ガイドライン
- 経済産業省とIPAが公開する経営層向けの指針。経営者が認識すべき3原則と、経営者がCISOなどの担当幹部に指示すべき重要10項目を示している。
例題 協力会社から常駐している技術者に、自社の課長が直接その日の作業内容と手順を指示している。契約は業務委託(請負)である。何が問題か。
請負では注文者が受託側の労働者に直接指揮命令できないため、この状態は偽装請負に当たる。指示は協力会社の現場責任者を通し、その責任者が自社の技術者に指示する形に改める必要がある。どうしても直接指示が必要な業務であれば、労働者派遣契約に切り替えるのが筋である。なお、派遣であれば派遣先が自社の情報セキュリティ規程を適用して守らせる。
例題 ISMS認証を取りたいという相談に対し、「JIS Q 27002に適合すれば認証が取れる」と説明された。正しいか。
正しくない。認証審査の基準となるのは要求事項を定めたJIS Q 27001であり、JIS Q 27002は管理策の実践の規範、すなわち27001を実装するための手引という位置づけである。27000は用語と概要を示す規格で、これも認証の基準ではない。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A 大分類2:企業と法務 中分類2:法務/労働基準法・労働者派遣法・中小受託取引適正化法(公正取引委員会)・公益通報者保護法・JIS Q 27000シリーズ・サイバーセキュリティ経営ガイドライン
関連分野(技術・管理・戦略)
ネットワークの基礎(守るために知っておくこと)
ネットワークの仕組みを、セキュリティを守る立場から必要な範囲で押さえます。どこで区切ればどこまで守れるのか、どの通信を止めればよいのかが判断できるようになります。
ネットワークは、つながる範囲によってLANとWANに分けられます。LANは事業所や建物の中など、自分たちで管理できる範囲のネットワーク。WANは離れた拠点どうしを通信事業者の回線でつないだ、自分たちでは管理しきれないネットワークです。セキュリティを考えるうえで大事なのは「どこまでが自分の管理下か」という線引きです。自社のLANの中は自分たちのルールで守れますが、インターネットを通る部分は誰が見ているか分かりません。だから外を通る通信は暗号化する、という発想になります。
通信の役割分担を7つの層に整理したのがOSI基本参照モデルです。下から物理層、データリンク層、ネットワーク層、トランスポート層、セション層、プレゼンテーション層、アプリケーション層。実際のインターネットで使われるTCP/IPは、これをネットワークインタフェース層・インターネット層・トランスポート層・アプリケーション層の4階層にまとめた形です。層を意識すると、対策の道具の選び方が分かります。パケットフィルタリング型のファイアウォールはネットワーク層とトランスポート層(IPアドレスとポート番号)を見て通す・通さないを決め、WAFやプロキシはアプリケーション層まで中身を見て判断します。だからSQLインジェクションのような中身の攻撃は、ポート番号だけを見るファイアウォールでは止められません。
ネットワーク機器も役割で覚えます。リピータハブは受け取った信号を全ポートへそのまま流すので、盗聴されやすく現在はほとんど使われません。スイッチングハブ(L2スイッチ)はMACアドレスを見て宛先のポートにだけ送ります。ルータはIPアドレスを見て別のネットワークへ中継する機器で、ネットワークどうしの境界に立ちます。ファイアウォールは境界で通信を選別し、プロキシサーバは社内の端末に代わって外部と通信して、URLフィルタリングやアクセスログの取得を行います。無線LANアクセスポイントは電波でLANに参加させる入口なので、ここの認証が甘いと建物の外から侵入されます。
IPアドレスは、ネットワーク部とホスト部に分かれています。どこまでがネットワーク部かを示すのがサブネットマスクで、これを変えるとネットワークを小さく区切れます。これがセキュリティ上とても重要です。部門ごと、用途ごとにサブネットを分けておけば、1台がマルウェアに感染しても被害が同じサブネットの中にとどまりやすく、境界のルータやファイアウォールで通信を止められます。逆に全社を1つの大きなネットワークにしていると、感染は一気に横に広がります。サーバだけを別区画(DMZ)に置く、来客用の無線LANを社内LANから切り離す、といった対策はすべてこの考え方です。プライベートIPアドレス(10.0.0.0〜、172.16.0.0〜、192.168.0.0〜)は組織の中だけで使うアドレスで、インターネットからは直接届きません。NAT/NAPTでグローバルIPアドレスに変換して外へ出ますが、これは節約のための仕組みであって、セキュリティ対策そのものではありません。外から直接届きにくいという副次的な効果はありますが、ファイアウォールの代わりにはなりません。
ポート番号は、同じ相手のどのサービスへの通信かを示す番号です。よく使うものは覚えておきましょう。HTTPが80、HTTPSが443、SMTPが25、POP3が110、IMAP4が143、DNSが53、SSHが22、FTPが20と21です。ファイアウォールの設定は「どのIPアドレスから、どのIPアドレスの、どのポート番号への通信を許すか」で書くので、ポート番号が分からないとルールが読めません。必要な通信だけを許可し、それ以外はすべて拒否する(デフォルト拒否)が原則です。DNSはドメイン名をIPアドレスに変換する仕組み、DHCPは端末にIPアドレスを自動で配る仕組みで、どちらも止まると業務が止まるうえ、偽の応答を返されると偽サイトへ誘導されます。
外を通る通信を守る代表がVPNです。インターネットの上に暗号化された仮想的な専用線をつくります。IPsec-VPNはネットワーク層で暗号化するので、拠点間をまるごとつなぐ用途に向きます。SSL-VPN(TLSを使うVPN)はWebブラウザからでも使え、在宅勤務の端末から社内へ入る用途でよく使われます。ただしVPNは「通り道を守る仕組み」であって、つないでくる端末が安全かどうかは別問題です。マルウェアに感染した自宅PCがVPNでつながれば、暗号化されたまま社内へマルウェアが入ってきます。VPN装置自体の脆弱性を放置して侵入される事故も多く、パッチ適用と多要素認証がセットで必要です。
無線LANは電波が壁を越えて届くので、有線より慎重に扱います。SSIDはアクセスポイントの識別名で、暗号化方式はWPA2かWPA3を使います。WEPは短時間で解読されるため使ってはいけません。SSIDのステルス機能(SSIDを電波にのせない設定)やMACアドレスフィルタリングは、まったく無意味ではないものの、通信を観測すればSSIDもMACアドレスも分かってしまうため、これだけを頼りにしてはいけません。守りの本体はあくまで暗号化と認証です。公衆無線LANでは、暗号化されていないアクセスポイントや、正規のものに似せた偽アクセスポイントに注意し、業務で使うならVPNを併用します。
メールはSMTPで送り、POP3またはIMAP4で受け取ります。POP3はメールを端末にダウンロードして管理する方式、IMAP4はサーバ上に置いたまま複数端末から見る方式です。メールは差出人を簡単に詐称できるので、なりすまし対策として送信ドメイン認証があります。SPFは「そのドメインのメールを送ってよいサーバのIPアドレス」をDNSに公開して照合する仕組み、DKIMは送信側が電子署名を付け、受信側がDNSの公開鍵で検証する仕組み、DMARCはSPFとDKIMの結果を踏まえて、認証に失敗したメールをどう扱うか(何もしない・隔離・拒否)を送信ドメイン側の方針として示し、結果の報告も受け取る仕組みです。
地味ですが重要なのがNTPによる時刻同期です。機器ごとに時計がずれていると、複数のログを時刻順に並べても事実の順序が分からず、いつ侵入されて何が起きたのかを追えません。証拠としての価値も下がります。だから社内の機器を共通のNTPサーバに同期させ、ログの時刻をそろえておくことが、インシデント調査と監査証跡の前提になります。最後に、5Gは高速・大容量・低遅延・多数同時接続が特徴で、IoT機器が大量にネットワークにつながる時代を支えています。IoT機器は初期パスワードのまま使われる、更新が提供されないといった弱点があり、乗っ取られてDDoS攻撃の踏み台にされます。IoT機器も資産として管理し、初期パスワードを変更し、業務ネットワークとは別のセグメントに置くのが基本です。
| 区分 | 項目 | 内容 | セキュリティ上の意味 |
|---|---|---|---|
| 階層と機器 | 物理層 | リピータ、リピータハブ | 受信信号を全ポートへ流すため盗聴されやすい |
| 階層と機器 | データリンク層 | ブリッジ、スイッチングハブ(L2スイッチ) | MACアドレスで宛先ポートだけに送るので無駄な流出が減る |
| 階層と機器 | ネットワーク層 | ルータ、L3スイッチ | ネットワークどうしの境界に立ち、区画を分ける要となる |
| 階層と機器 | ネットワーク層〜トランスポート層 | パケットフィルタリング型ファイアウォール | IPアドレスとポート番号で通す・通さないを決める |
| 階層と機器 | アプリケーション層 | プロキシサーバ、WAF | 通信の中身まで見る。URLフィルタリングやログ取得、Web攻撃の遮断 |
| プロトコルとポート | HTTP/HTTPS | 80/443 | HTTPは平文。業務では必ずHTTPSに限定する |
| プロトコルとポート | SMTP | 25 | メール送信。外部への直接送信を絞り、送信ドメイン認証と併用する |
| プロトコルとポート | POP3/IMAP4 | 110/143 | メール受信。平文のままでは盗聴されるためTLSで保護する |
| プロトコルとポート | DNS | 53 | 名前解決。偽応答を返されると偽サイトへ誘導される |
| プロトコルとポート | SSH | 22 | 暗号化された遠隔操作。インターネットへの開放は最小限にする |
| プロトコルとポート | FTP | 20/21 | 平文で認証情報が流れる。SFTPやFTPSに置き換える |
| 守る仕組み | サブネット分割・DMZ | 部門別・用途別にネットワークを区切る | 感染の横展開を区画内に閉じ込める内部対策 |
| 守る仕組み | VPN(IPsec/SSL-VPN) | 公衆網の上に暗号化された通り道をつくる | 経路は守れるが接続端末の安全性は別途確保が必要 |
| 守る仕組み | WPA2/WPA3 | 無線LANの暗号化と認証 | WEPは使用不可。ステルスSSIDやMACフィルタは補助にすぎない |
| 守る仕組み | NTP | 機器の時刻をそろえる | ログの突合せができ、証拠としての価値が保たれる |
- OSI基本参照モデル
- 通信の役割を物理層からアプリケーション層までの7階層に整理した国際的な参照モデル。どの層で守る対策なのかを整理するのに使う。ファイアウォールはネットワーク層・トランスポート層、WAFやプロキシはアプリケーション層で働く。
- サブネット
- サブネットマスクによって大きなネットワークを小さく区切った単位。部門や用途ごとに分けておくと、1台が感染しても被害が区画内にとどまりやすく、境界の機器で通信を遮断して封じ込められる。
- プライベートIPアドレス
- 10.0.0.0、172.16.0.0、192.168.0.0で始まる範囲など、組織内だけで自由に使えるIPアドレス。インターネット上では使えず直接は届かないが、それ自体はセキュリティ対策ではなくファイアウォールの代わりにはならない。
- NAT/NAPT
- プライベートIPアドレスとグローバルIPアドレスを変換する仕組み。NAPTはポート番号も併せて変換し、1つのグローバルアドレスを多数の端末で共有できる。目的はアドレスの節約であって、防御機能ではない。
- ポート番号
- 同じ機器上のどのサービス宛ての通信かを示す番号。HTTP80、HTTPS443、SMTP25、POP3が110、IMAP4が143、DNS53、SSH22、FTP20/21。ファイアウォールのルールはIPアドレスとポート番号の組合せで書く。
- DMZ
- 外部に公開するサーバを、社内LANともインターネットとも切り離した中間の区画に置く構成。公開サーバが侵害されても、そこから社内LANへ直接入れないようにするための区画分けである。
- VPN
- インターネットなどの公衆網の上に、暗号化によって仮想的な専用線をつくる技術。ネットワーク層で暗号化するIPsec-VPNと、TLSを使いブラウザからも利用できるSSL-VPNがある。通り道は守るが、接続してくる端末の安全性は別に確保する必要がある。
- WPA2/WPA3
- 無線LANの暗号化・認証方式。WPA3が最新で、WPA2も現在広く使われる。旧方式のWEPは短時間で解読可能なため使用してはならない。SSIDのステルス化やMACアドレスフィルタは補助にすぎない。
- SPF/DKIM/DMARC
- メールの送信ドメインを認証する仕組み。SPFは送信元サーバのIPアドレスをDNSで照合し、DKIMは電子署名を検証する。DMARCは両者の結果を踏まえた取扱い方針(なし・隔離・拒否)を公開し、認証結果の報告も受け取る。
- NTP
- ネットワーク上の機器の時刻を合わせるプロトコル。機器間で時刻がずれているとログを時系列で突き合わせられず、インシデントの原因究明も監査証跡としての証明力も損なわれる。
例題 社内の部門ごとにサブネットを分けておくと、セキュリティ上どのような効果があるか。
1台の端末がマルウェアに感染しても、被害が同じサブネットの中にとどまりやすくなり、境界のルータやファイアウォールで通信を遮断して封じ込められる。全社を1つの大きなネットワークにしていると、感染は社内全体へ一気に広がる。区画分けは外からの侵入を防ぐ対策ではなく、侵入されたあとの被害を小さくする内部対策である。
例題 在宅勤務でVPNを使えば、接続元のPCのセキュリティ対策は不要になるか。
ならない。VPNが守るのは通信経路の秘密性と完全性であって、接続してくる端末が安全かどうかは保証しない。感染したPCからVPNでつなげば、暗号化されたまま社内へマルウェアが入ってくる。端末側のパッチ適用・マルウェア対策・多要素認証をあわせて実施する必要がある。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A テクノロジ系(ネットワーク方式、通信プロトコル、ネットワーク応用)/同 大分類1:技術要素 中分類1:セキュリティ 小分類4 情報セキュリティ対策
システムとデータの基礎
システムの構成、止まらない仕組み、データベースの守り方を押さえます。クラウドでどこまでが自分の責任なのかが分かるようになります。
システムの基本形はクライアントサーバです。利用者が使う側(クライアント)と、処理やデータを預かる側(サーバ)に役割を分けます。Webシステムはその代表で、ブラウザさえあれば使えるかわり、Webサーバが侵害されると大量の利用者に影響が及びます。仮想化は1台の物理サーバの上に複数の仮想サーバを動かす技術で、資源を効率よく使えますが、土台の物理サーバやハイパバイザが侵害されると、その上のすべての仮想サーバに影響します。仮想サーバも1台のサーバとして、パッチ適用・アカウント管理・ログ取得が必要です。
クラウドサービスは、どこまでを事業者が提供するかで3つに分かれます。IaaSはサーバやストレージ、ネットワークといったインフラだけを提供するので、利用者はゲストOS、ミドルウェア、アプリケーション、データ、アカウントを自分で管理します。PaaSはOSやミドルウェアまで事業者が用意し、利用者はその上で動かすアプリケーションとデータ、アカウントに責任を持ちます。SaaSは完成したアプリケーションを使う形なので、利用者の責任はデータそのものと、利用者アカウントや共有設定・アクセス権の設定に絞られます。これを責任共有モデル(責任分界)といいます。重要なのは「クラウドにしたから安全になる」わけではないことです。実際の事故の多くは、事業者側の障害ではなく、利用者が設定したアクセス権や公開範囲の誤りによる情報漏えいです。どの形態でも、自社のデータと利用者アカウントの管理からは逃れられません。契約前には、事業者の管理水準、データの保存場所、障害時の責任範囲、監査報告書の有無、契約終了時のデータ返却と消去を確認します。
止まらない仕組みが可用性です。デュアルシステムは同じ処理を2系統で並行して行って結果を照合する方式、デュプレックスシステムは主系が動き、待機系を用意しておく方式です。待機系にあらかじめ電源を入れてすぐ切り替えられる状態にしておくのがホットスタンバイ、停止させておいて必要時に起動するのがコールドスタンバイです。切替えが速いほど費用はかかるので、事業への影響度に見合った構成を選びます。可用性を上げる構成は、そのまま事業継続(BCP)につながります。
稼働率は、システムが使える状態にある時間の割合です。すべての装置が動かないと動かない構成(直列)では、全体の稼働率は各装置の稼働率の積になります。稼働率0.9の装置2台が直列なら0.9×0.9=0.81です。台数を増やすほど全体は下がります。どれか1つ動けばよい構成(並列・冗長化)では、全体の稼働率は1から「全部が同時に止まる確率」を引いて求めます。0.9の装置2台の並列なら1−(1−0.9)×(1−0.9)=0.99です。冗長化すると稼働率が上がることが数字で確認できます。関連する指標として、平均故障間隔(MTBF)は故障せずに動いている時間の平均、平均修復時間(MTTR)は復旧にかかる時間の平均で、稼働率はMTBF÷(MTBF+MTTR)で表されます。性能の指標では、単位時間に処理できる仕事量がスループット、要求を出してから応答が返るまでの時間がレスポンスタイムです。
データを守る仕組みも押さえます。RAIDは複数のディスクを組み合わせて、ディスクが1台壊れてもデータを失わないようにする技術です。RAID1(ミラーリング)は同じ内容を2台に書き、RAID5はパリティを分散して記録します。ただしRAIDが守るのはディスクの故障だけです。誤ってファイルを消した場合も、ランサムウェアに暗号化された場合も、その操作はそのまま全ディスクに反映されます。だからRAIDはバックアップの代わりになりません。バックアップは、世代を複数残し、少なくとも1つはネットワークから切り離した場所(オフライン)または遠隔地に保管します。ランサムウェアは共有フォルダ上のバックアップまで暗号化しにいくからです。そして復元できることを定期的に試すこと。取っているつもりで戻せないバックアップは、無いのと同じです。
データベースは、データを表(テーブル)の形で管理し、DBMSというソフトウェアが利用者からの要求をまとめて処理します。表の中で1行を一意に識別する列が主キーで、空にできず重複もできません。正規化は、同じデータがあちこちに重複して持たれる状態をなくし、更新時の矛盾(更新のたびに片方だけ直ってしまう、といった不整合)を防ぐための整理です。トランザクションは、一連の処理をまとめて「全部やる」か「全部やらない」かにする単位で、その性質をACID(原子性・一貫性・独立性・耐久性)と呼びます。障害が起きたときは、バックアップとログを使って復旧します。処理途中で中断したものを取り消して開始前に戻すのがロールバック、バックアップ時点に更新後ログを反映して障害直前まで進めるのがロールフォワードです。ログが無ければどちらもできないので、ログの保全そのものが可用性の要になります。
データベースのセキュリティでは、まずアクセス権です。利用者や役割ごとに、どの表のどの操作(参照・追加・更新・削除)を許すかを設定し、業務に必要な最小限にとどめます。特定の列や行だけを見せたいときはビューが有効です。たとえば人事の表から、氏名と所属だけを取り出したビューを作って一般の利用者に参照権限を与えれば、給与や個人番号の列には触れさせずに済みます。さらに、機微なデータは列単位で暗号化する、データベースファイルやバックアップ全体を暗号化するといった対策を重ねます。暗号化されていれば、媒体やバックアップが盗まれても内容を読み取られません。あわせて、誰がいつどのデータにアクセスしたかのアクセスログを取得し、保管します。
運用面では、OSやソフトウェアのパッチ適用を計画的に行うこと。脆弱性が公表されてから攻撃が始まるまでの時間は年々短くなっており、放置は侵入の入口になります。サポートが終了した製品は修正が提供されないので、更新できないなら使い続けない、が原則です。OSS(オープンソースソフトウェア)は自由に利用・改変・再配布ができますが、ライセンス条件を守る義務があり、脆弱性情報や更新は自分で追いかけて適用する必要があります。無償だから責任がないのではなく、使う側が管理する責任を負うと考えます。記憶媒体を廃棄するときは、ファイル削除やクイックフォーマットではデータが残るため、専用ソフトによる上書き消去、暗号化消去、または物理的な破壊を行い、その記録を残します。
| 区分 | 項目 | 内容 | セキュリティ上の意味 |
|---|---|---|---|
| 責任分界 | IaaS | 事業者は施設・ハードウェア・仮想化基盤まで。利用者はゲストOS以上 | OSのパッチ適用も利用者の責任。放置すれば侵入される |
| 責任分界 | PaaS | 事業者はOS・ミドルウェア・実行環境まで。利用者はアプリとデータ | 自作アプリの脆弱性(SQLインジェクション等)は利用者が塞ぐ |
| 責任分界 | SaaS | 事業者はアプリケーションまで。利用者はデータとアカウント・権限設定 | 公開範囲や共有設定の誤りによる漏えいは利用者の責任 |
| 責任分界 | 全形態に共通 | データそのもの、利用者アカウント、アクセス権の設定 | クラウドにしても、この部分の責任は決して移らない |
| 責任分界 | 契約時の確認 | データの保存場所、監査報告書、障害時の責任、終了時のデータ返却と消去 | 確認しないまま契約すると、事故時に何もできない |
| 可用性の構成 | デュアルシステム | 2系統で同じ処理を行い結果を照合する | 誤りの検出もでき信頼性が高いが費用も高い |
| 可用性の構成 | デュプレックス(ホットスタンバイ) | 待機系を起動済みにして即座に切り替える | 停止時間が短く、事業継続への影響を抑えられる |
| 可用性の構成 | デュプレックス(コールドスタンバイ) | 待機系は停止させておき必要時に起動する | 安価だが復旧に時間がかかる。許容停止時間との兼合いで選ぶ |
| 可用性の構成 | 直列構成の稼働率 | 各装置の稼働率の積(例 0.9×0.9=0.81) | つなぐ装置が増えるほど全体は止まりやすくなる |
| 可用性の構成 | 並列(冗長)構成の稼働率 | 1−(1−A)×(1−B)(例 1−0.1×0.1=0.99) | 冗長化すると全体の稼働率が上がり事業継続に寄与する |
| データを守る | RAID | ディスク故障に備える冗長化 | 誤削除やランサムウェア暗号化は防げず、バックアップの代替にならない |
| データを守る | バックアップ | 複数世代を保持し、オフラインまたは遠隔地にも保管 | ランサムウェア対策の要。復元試験まで行って初めて有効 |
| データを守る | アクセス権とビュー | 役割ごとに必要最小限の操作だけ許可し、見せる列を絞る | 内部からの不必要な閲覧・持出しを構造的に防ぐ |
| データを守る | 暗号化とログ | 機微な列やバックアップを暗号化し、アクセスログを保管 | 媒体が盗まれても読まれず、不正な操作を追跡できる |
- IaaS
- サーバ、ストレージ、ネットワークといったインフラを提供するクラウドサービス。ゲストOSより上(OSのパッチ適用、ミドルウェア、アプリケーション、データ、アカウント)は利用者の責任範囲になる。
- PaaS
- OSやミドルウェア、実行環境まで事業者が用意するクラウドサービス。利用者はその上で動くアプリケーションの脆弱性対策、データ、アカウント管理に責任を持つ。
- SaaS
- 完成した業務アプリケーションを利用する形態のクラウドサービス。利用者の責任はデータと利用者アカウント、共有・公開範囲やアクセス権の設定に絞られるが、そこは必ず利用者が守る必要がある。
- 責任共有モデル
- クラウドの安全確保について、事業者と利用者のどちらが何を守るかを分ける考え方。IaaS→PaaS→SaaSの順で事業者の担当範囲が広がるが、データと利用者アカウントの管理はどの形態でも利用者の責任として残る。
- ホットスタンバイ
- 待機系にあらかじめ電源を入れ、すぐに切り替えられる状態で待たせておく冗長構成。切替えが速く停止時間が短いが費用は高い。停止させておくコールドスタンバイは安価だが復旧に時間がかかる。
- 稼働率
- システムが使える状態にある時間の割合。MTBF÷(MTBF+MTTR)で表される。直列構成では各装置の稼働率の積、並列(冗長)構成では1から全装置が同時に停止する確率を引いた値になる。
- MTBF/MTTR
- MTBFは平均故障間隔で、故障せずに動作している時間の平均。MTTRは平均修復時間で、故障してから復旧するまでの時間の平均。MTBFを延ばすか、MTTRを短くすると稼働率が上がる。
- RAID
- 複数のディスクを組み合わせ、1台が故障してもデータを失わないようにする技術。RAID1はミラーリング、RAID5はパリティの分散記録。守れるのはディスク故障だけで、誤削除やランサムウェアによる暗号化は全ディスクに反映されるためバックアップの代替にはならない。
- トランザクションとACID
- 一連の処理を全部実行するか全部取り消すかにまとめた単位がトランザクション。原子性・一貫性・独立性・耐久性という4つの性質をACID特性と呼び、途中で障害が起きても矛盾した状態を残さないことを保証する。
- ロールバック/ロールフォワード
- ロールバックは処理途中で中断したトランザクションを取り消して開始前の状態に戻す復旧。ロールフォワードはバックアップに更新後ログを反映して障害直前の状態まで進める復旧。どちらもログの保全が前提となる。
- ビュー
- 元の表から必要な列や行だけを取り出して定義する仮想的な表。給与などの列を除いたビューだけに参照権限を与えれば、利用者に見せる範囲を限定でき、最小権限の原則を実現しやすい。
例題 SaaSの業務システムで、利用者が誤って社外の誰でも閲覧できる共有設定にしたためファイルが漏えいした。この責任は誰にあるか。
利用者(契約した組織)側にある。SaaSではアプリケーションの稼働と脆弱性対策は事業者の責任だが、データそのものと利用者アカウント、共有・公開範囲やアクセス権の設定は利用者の責任範囲として残る。クラウドを使っても、この部分の責任は事業者へ移らない。
例題 稼働率0.9の装置を2台使う。直列構成と並列(どちらか1台動けばよい)構成で、システム全体の稼働率はそれぞれいくらか。
直列は0.9×0.9=0.81(81%)。並列は1−(1−0.9)×(1−0.9)=1−0.01=0.99(99%)。直列は装置を増やすほど全体が下がり、並列は冗長化によって上がる。可用性を高めたい部分は並列(冗長)構成にする、という判断につながる。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A テクノロジ系(システム構成要素、データベース、ソフトウェア)/同 大分類1:技術要素 中分類1:セキュリティ 小分類4 情報セキュリティ対策
開発とサービスの管理
システムを作る流れと、動かし続ける仕組みを押さえます。どの段階でセキュリティを組み込むべきか、監査は何のためにあるのかが分かるようになります。
システム開発は、要件定義→設計(外部設計・内部設計)→実装(プログラミング)→テスト→運用・保守、という流れで進みます。要件定義は「何ができるシステムにするか」を決める段階で、利用部門が主役です。ここでの決めごとが後工程すべてを縛ります。セキュリティで最も大事なのは、この要件定義の段階でセキュリティ要件を書き込むことです。アクセス権をどう分けるか、ログを何をどれだけ残すか、通信と保存データを暗号化するか、認証を多要素にするか。こうしたことを最初から設計に織り込む考え方をセキュリティバイデザインといいます。完成してから後付けしようとすると、設計に手を入れる大工事になり、費用も期間も何倍にもなります。多くの場合、直しきれずに危ない状態のまま運用が始まってしまいます。だから「後から付ける」のではなく「最初から入れる」のです。
テストにはいくつかの見方があります。ホワイトボックステストは、プログラムの内部構造を見て、命令や分岐が漏れなく通るかを確かめる方法。ブラックボックステストは、内部構造は見ずに、入力に対して仕様どおりの出力が返るかを確かめる方法です。これに対しペネトレーションテスト(侵入テスト)は、攻撃者の立場で実際に侵入を試み、防御を突破できてしまうかを確認するテストです。目的が違うので、機能テストが全部合格していても、ペネトレーションテストで侵入できてしまうことは普通にあります。脆弱性診断やペネトレーションテストは、本番稼働前に実施し、見つかった弱点を直してから公開するのが原則です。なお、他人が管理するシステムに対して許可なく侵入を試みる行為は不正アクセス禁止法に触れるため、必ず事前に管理者の書面による承諾を得て、範囲と期間を決めて実施します。
プロジェクトマネジメントは、期限のある一度きりの活動を計画どおり終わらせるための管理です。対象範囲を決めるスコープ管理、日程のスケジュール管理、費用のコスト管理、品質管理、要員の資源管理、関係者への伝え方を決めるコミュニケーション管理、そしてリスク管理と調達管理があります。セキュリティの観点では、リスク管理で「情報漏えい」「納期遅延によるテスト省略」といった脅威をあらかじめ洗い出しておくこと、調達管理で外部委託先に守らせるセキュリティ要件を契約に書き込むことが要になります。スコープを途中で無制限に広げると、しわ寄せがテスト工程に来て、セキュリティの確認が省かれます。
作ったシステムを安定して提供し続けるための管理がサービスマネジメントです。SLA(サービスレベル合意書)は、提供者と利用者の間で、サービスの品質水準を数値で合意した文書です。稼働率、障害時の復旧目標時間、問合せへの応答時間などを定めます。決めた水準を継続的に測定・評価し、改善していく活動全体がSLM(サービスレベル管理)です。SLAには可用性だけでなく、セキュリティに関する事項(インシデント発生時の報告期限、ログの保存期間、脆弱性への対応時間など)も入れておくと、いざというときに何をしてもらえるかが明確になります。窓口としてはサービスデスクを一本化し、利用者からの問合せや障害の申告をすべてそこで受け付けます。窓口が一つなら、記録が集まり、複数の申告から異常の兆候に気づけます。
サービスマネジメントの主なプロセスを整理します。インシデント管理は、サービスの中断や品質低下が起きたとき、できるだけ早く通常のサービスに戻すことが目的です。原因が分からなくても、暫定的な回避策で業務を戻してかまいません。問題管理は、インシデントの根本原因を突き止め、恒久的な対策によって再発を防ぐことが目的です。「目の前の火を消すのがインシデント管理、火元を直すのが問題管理」と覚えると混同しません。両者は目的が違うので、別のプロセスとして管理します。変更管理は、システムへの変更を無秩序に行わせず、影響を評価し、承認を得てから実施し、記録する仕組みです。承認されていない変更を防ぐこと自体がセキュリティ対策になります。構成管理は、機器・ソフトウェア・設定といった構成要素とその関係を正確に把握し続ける活動で、脆弱性が公表されたときに「うちのどれが該当するか」をすぐに特定できる状態を作ります。リリース管理は変更を本番環境へ確実に反映する活動、可用性管理は合意した稼働水準を維持する活動、容量・能力管理は必要な処理能力を確保する活動です。
システム監査は、情報システムが適切に管理・運用されているかを、独立した立場の監査人が点検・評価し、改善につなげる仕組みです。ここで最も重要なのが独立性です。監査人は、監査の対象となる部門から独立していなければなりません。自分が構築や運用に関わったシステムを自分で監査すれば、都合の悪いことを見逃す(または見逃したと疑われる)からです。組織上の身分が独立していること(外観上の独立性)と、公正・客観的な判断ができること(精神上の独立性)の両方が求められます。情報システム部門の担当者が自部門の運用を監査することは、たとえ本人が公正でも独立性の要件を満たしません。
監査は、計画(監査計画の策定)→予備調査→本調査→評価・結論→報告→フォローアップ、という手順で進みます。監査人は、自分の意見を裏づける証拠として監査証拠を集め、それをどのように評価し結論に至ったかを監査調書に記録します。監査証跡とは、処理がいつ誰によってどのように行われたかを、記録によって遡って追跡できる仕組み・記録のことです。アクセスログ、操作履歴、承認記録などがこれにあたり、監査証跡があるからこそ事後の検証ができます。監査の結果は監査報告書として依頼者(一般には経営者)へ報告し、指摘した事項について改善が実行されたかを確認するのがフォローアップです。ここで注意したいのは、改善そのものを実施するのは被監査部門であり、監査人ではないという点です。監査人が自ら改善策を実施してしまえば、次の監査で自分の仕事を監査することになり、独立性が失われます。
内部統制は、業務を有効かつ効率的に行い、財務報告の信頼性を確保し、法令を守り、資産を保全するために、組織の中に組み込む仕組みです。その代表的な考え方が職務分掌で、1人の担当者が申請から承認、実行、記録までを一貫して行えないように役割を分け、相互に牽制させます。発注する人と検収する人を分ける、システムの開発担当者に本番環境の変更権限を与えない、といった形です。これは特定の人を疑う話ではなく、不正が起きにくい構造をあらかじめ作っておくという話です。そしてITガバナンスは、経営者がITの活用を統制し、企業価値の向上につなげる責任を負うという考え方で、セキュリティ投資の判断や方針の承認は経営者の役割になります。
| 区分 | 項目 | 目的・内容 | セキュリティ上の意味 |
|---|---|---|---|
| サービス管理 | サービスデスク | 問合せ・障害申告を受ける単一の窓口 | 記録が集まり、異常の兆候を早期に把握できる |
| サービス管理 | インシデント管理 | できるだけ早く通常のサービスへ戻す | 暫定回避策でもよい。まず業務影響を止める |
| サービス管理 | 問題管理 | 根本原因を究明し恒久対策で再発を防ぐ | 同じ事故を繰り返さないための仕組み |
| サービス管理 | 変更管理 | 影響評価と承認を経てから変更を実施し記録する | 未承認の変更を防ぐこと自体が対策になる |
| サービス管理 | 構成管理 | 機器・ソフト・設定と相互関係を正確に把握する | 脆弱性公表時に該当資産を即座に特定できる |
| サービス管理 | 可用性管理 | 合意した稼働水準を維持する | 事業継続に直結する。SLAの数値と結びつく |
| サービス管理 | SLA/SLM | 品質水準を数値で合意し、測定・評価・改善する | 報告期限やログ保存期間などセキュリティ事項も定める |
| 監査の手順 | 1 監査計画の策定 | 対象・範囲・時期・体制を決める | リスクの大きい領域を優先して計画する |
| 監査の手順 | 2 予備調査 | 資料や規程を確認し対象の概要を把握する | 本調査で確かめるべき論点を絞り込む |
| 監査の手順 | 3 本調査 | 証拠を集め、事実を確かめる | ログや承認記録など監査証跡が判断の裏づけになる |
| 監査の手順 | 4 評価・結論 | 監査証拠に基づき評価し、監査調書に残す | 結論の根拠を記録で示せることが求められる |
| 監査の手順 | 5 報告 | 監査報告書を依頼者(経営者)へ提出する | 改善の必要性を経営層に伝える |
| 監査の手順 | 6 フォローアップ | 指摘事項の改善状況を確認する | 改善の実施は被監査部門。監査人は確認にとどまる |
| 開発とテスト | セキュリティバイデザイン | 要件定義の段階でセキュリティ要件を定義する | 後付けは大規模な手戻りとなり不十分になりやすい |
| 開発とテスト | ペネトレーションテスト | 攻撃者の立場で侵入可能性を確認する | 機能テスト合格でも侵入できる場合がある。事前承諾が必要 |
- セキュリティバイデザイン
- 企画・要件定義の段階からセキュリティを設計に組み込む考え方。後工程で追加すると設計変更を伴い費用と期間が膨らみ、対策が不十分なまま運用開始となりやすいため、最初から要件として定義する。
- ペネトレーションテスト
- 攻撃者の立場で実際に侵入を試み、防御を突破できるかを確認するテスト。機能が仕様どおり動くかを見るホワイトボックス/ブラックボックステストとは目的が異なる。実施には対象システム管理者の事前承諾が必要。
- SLA/SLM
- SLAは提供者と利用者がサービス品質の水準を数値で合意した文書。稼働率や復旧目標時間に加え、インシデント報告期限やログ保存期間などセキュリティ事項も定める。SLMはその水準を測定・評価し改善し続ける管理活動。
- サービスデスク
- 利用者からの問合せ、障害申告、要望を一元的に受け付ける単一の窓口。記録が一か所に集まるため、複数の申告からインシデントの兆候を早期に把握でき、対応漏れも防げる。
- インシデント管理
- サービスの中断や品質低下から、できるだけ早く通常の状態へ戻すことを目的とするプロセス。根本原因が未解明でも、暫定的な回避策で業務を復旧させてよい点が問題管理との大きな違い。
- 問題管理
- インシデントの根本原因を究明し、恒久的な対策によって再発を防ぐことを目的とするプロセス。早期復旧を目的とするインシデント管理とは目的が異なるため、別のプロセスとして管理する。
- 変更管理
- システムへの変更について影響を評価し、承認を得てから計画的に実施し、記録する仕組み。承認されていない変更や場当たり的な設定変更を防ぐこと自体がセキュリティ対策になる。
- 構成管理
- 機器、ソフトウェア、バージョン、設定などの構成要素とその関係を正確に把握し続ける活動。脆弱性が公表されたとき、該当する資産をすぐ特定して対処できる状態を作る。
- システム監査人の独立性
- 監査人が被監査部門から組織上独立していること(外観上の独立性)と、公正・客観的に判断できること(精神上の独立性)。自ら構築・運用に関与したシステムを監査してはならず、改善の実施も被監査部門が行う。
- 監査証跡
- 処理がいつ誰によってどのように行われたかを、記録によって順に遡って追跡できる仕組みや記録。アクセスログ、操作履歴、承認記録などが該当し、事後の検証と不正の抑止に役立つ。
- 職務分掌
- 申請・承認・実行・記録といった役割を複数の人に分け、相互に牽制させる内部統制の基本的な仕組み。1人で一連の処理を完結できなくすることで、不正やミスが起きにくい構造をつくる。
例題 業務システムが停止した。原因は不明だが、サーバを再起動したところ復旧した。この対応はインシデント管理と問題管理のどちらにあたるか。
インシデント管理にあたる。インシデント管理の目的はサービスの早期復旧であり、根本原因が分からなくても暫定的な回避策で業務を戻してよい。このあと、なぜ停止したのかを調べて恒久対策を講じ、再発を防ぐ活動が問題管理である。両者は目的が違うため、別のプロセスとして扱う。
例題 情報システム部門の運用担当者が、自部門の運用状況をシステム監査人として監査してよいか。
よくない。システム監査人には被監査部門からの独立性が求められ、自ら構築・運用に関与した対象を監査すると、公正な評価ができない、または疑われる。組織上の独立(外観上の独立性)と公正な判断(精神上の独立性)の両方が必要で、独立した内部監査部門や外部の監査人が行う。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A マネジメント系(システム開発技術、プロジェクトマネジメント、サービスマネジメント、システム監査)
経営と戦略の基礎
企業がどう動き、どう投資を決めるかを押さえます。セキュリティが経営の課題であること、委託先や生成AIをどう扱うかが分かるようになります。
企業は経営理念を掲げ、それを実現するために経営戦略を立て、組織をつくって活動します。改善を回す基本の型がPDCAサイクル(計画→実行→評価→改善)で、ISMSもこの型で運用されます。組織形態には、職能ごとに分ける職能別組織、製品や地域ごとに分ける事業部制組織、職能と事業の両方の指揮系統を持つマトリックス組織、特定の目的のために一時的に編成するプロジェクト組織などがあります。経営層の役割では、CEOが経営全般の最高責任者、CIOが情報システム全体の戦略と活用に責任を持つ最高情報責任者、CISOが情報セキュリティに関する最高責任者です。CISOは、セキュリティ方針の策定、リスクへの対応方針の決定、インシデント発生時の指揮、経営層への報告といった責任を負います。セキュリティを情報システム部門の一担当者に任せきりにせず、経営層に責任者を置くこと自体が、組織としてセキュリティに取り組む姿勢を示します。
コーポレートガバナンス(企業統治)は、経営者が適切に経営を行っているかを、株主など外部の視点も入れて監督する仕組みです。社外取締役や監査役の設置、情報開示などがその手段になります。内部統制は、業務の有効性・効率性、財務報告の信頼性、法令等の遵守、資産の保全を達成するために、組織の中に組み込む仕組みで、経営者が整備・運用の責任を負います。職務分掌による相互牽制、承認手続、記録の保存などが具体策です。情報セキュリティは、この内部統制の一部として位置づけられます。あわせて、企業が社会に対して負う責任がCSRで、環境や人権への配慮、コンプライアンスなどが含まれます。SDGsは国連が採択した2030年までの持続可能な開発目標で、企業活動の方向づけにも使われます。個人データを適切に扱うことは、いまや社会的責任の一部です。
財務の基礎も少し押さえます。損益計算書では、売上高から売上原価を引いた売上総利益、そこから販売費及び一般管理費を引いた営業利益、それに営業外の収益と費用を加減した経常利益、といった段階で利益を見ます。損益分岐点は、売上高と費用がちょうど等しくなり利益がゼロになる売上高のことで、これを超えると利益が出ます。費用は、売上に応じて増える変動費と、売上に関係なくかかる固定費に分けて考えます。セキュリティ投資も同じ土俵で説明する必要があります。対策には費用がかかりますが、事故が起きたときの損失(復旧費用、賠償、売上機会の損失、信用の失墜)と比べて説明するのが基本です。想定される年間の損失額(発生確率×1回あたりの損失)が対策によってどれだけ減るかと、対策の年間費用を比べて、投資の妥当性を判断します。損失額をはるかに超える費用をかけるのも、明らかに小さい費用を惜しんで大きな損失を招くのも、どちらも経営判断としては誤りです。ただし、人命や法令遵守に関わるものは費用対効果だけで判断しません。
システム戦略は、経営戦略を実現するために情報システムをどう活用するかの方針です。情報システム戦略は経営戦略と整合していなければならず、情報システム部門が単独で決めるものではありません。EA(エンタープライズアーキテクチャ)は、組織の業務とシステムの全体像をビジネス・データ・アプリケーション・技術の各体系で描き、現状と理想を対比して移行計画を立てる手法です。DX(デジタルトランスフォーメーション)は、データとデジタル技術を活用して製品・サービスやビジネスモデル、業務そのものを変革し、競争上の優位を確立することを指します。単なるIT化・電子化ではなく、変革であるという点が重要です。DXを進めるほど扱うデータは増え、外部とのつながりも増えるので、セキュリティの確保が前提条件になります。守りが弱いまま進めれば、変革の成果ごと失うことになります。
システム企画から調達までの流れも定番です。まず情報提供依頼書(RFI)を出して、市場にどんな製品・サービス・技術があるかの情報を集めます。次に、集めた情報をもとに要件を整理し、提案依頼書(RFP)を作って複数のベンダに提示します。RFPには、システムに求める機能、性能、予算、納期、体制、そしてセキュリティ要件を明記します。ベンダから提案書と見積書を受け取り、あらかじめ決めた基準で評価して発注先を選定し、契約を締結します。順序はRFI→RFP→提案書→契約です。情報を集める段階が先で、提案を求める段階が後、と押さえておけば迷いません。
委託先の選定では、価格と納期だけで決めてはいけません。セキュリティを評価項目に入れます。ISMS(JIS Q 27001)認証やプライバシーマークの取得状況、再委託の可否と再委託先の管理方法、従業員への教育と守秘義務契約、事故が起きたときの報告義務と期限、監査を受け入れる条項、契約終了時のデータの返却・消去の方法。これらを選定基準と契約書に明記します。そして忘れてはならないのが、委託しても責任は委託元に残るという原則です。個人データの取扱いを委託した場合、委託元には委託先に対する必要かつ適切な監督の義務があります。委託先で漏えいが起きても「任せていたので知らない」では済まされず、委託元の管理責任が問われます。契約して終わりではなく、定期的に報告を受け、状況を確認し続けることが必要です。
経営戦略を考えるための分析手法もいくつか出てきます。SWOT分析は、内部環境の強み(Strength)と弱み(Weakness)、外部環境の機会(Opportunity)と脅威(Threat)の4つに整理する手法。3C分析は顧客(Customer)・競合(Competitor)・自社(Company)の視点で市場を見る手法。PPM(プロダクトポートフォリオマネジメント)は、市場成長率と市場占有率の2軸で事業や製品を「花形」「金のなる木」「問題児」「負け犬」に分類し、経営資源の配分を考える手法です。目標の管理では、最終的に達成すべき成果指標がKGI、それを達成するために決定的に重要な要因がCSF、進捗を測る中間的な指標がKPIです。セキュリティにもこの考え方は使えます。たとえばKGIを「重大インシデントの発生ゼロ」とし、CSFを「全従業員のセキュリティ意識向上」、KPIを「標的型攻撃メール訓練の開封率」「教育の受講率」「脆弱性の平均修正日数」と置けば、活動の進み具合を数字で経営層に説明できます。
最後に生成AIの業務利用です。文章や画像を作れる便利な道具ですが、留意点が3つあります。第一にハルシネーション。生成AIは、事実でない内容をもっともらしい文章で出力することがあります。出力をそのまま正しいものとして使わず、必ず人が事実確認をしてから使います。第二に入力情報の漏えい。入力した内容が学習に使われたり、事業者側に保存されたりする場合があり、顧客の個人情報、未公表の経営情報、ソースコードなどを安易に入力すると、そこから外部へ出ていく恐れがあります。だから「何を入力してよいか/いけないか」を利用ルールとして定め、機密情報の入力を禁止し、業務での利用は組織が承認したサービスに限定します。個人が勝手に使う状態(シャドーIT)は特に危険です。第三に著作権など権利の問題。生成物が既存の著作物に似てしまう場合があり、そのまま公表・販売すると権利侵害になる恐れがあります。利用規約で商用利用の可否も確認します。要するに、生成AIは「下書きを作る道具」として使い、最終的な確認と責任は人が持つ、というのが基本の姿勢です。
| 区分 | 項目 | 内容 | セキュリティ上の意味 |
|---|---|---|---|
| 調達の流れ | 1 情報提供依頼(RFI) | 市場の製品・サービス・技術の情報をベンダから集める | 実現可能なセキュリティ水準の相場観をここで掴む |
| 調達の流れ | 2 提案依頼(RFP) | 要件・予算・納期・体制を示して提案を依頼する | セキュリティ要件をRFPに明記しないと提案にも契約にも入らない |
| 調達の流れ | 3 提案書・見積書の受領 | ベンダから具体的な提案と費用を受け取る | 認証取得状況や再委託の扱いを提案内容で確認する |
| 調達の流れ | 4 評価・選定 | あらかじめ決めた基準で比較し発注先を決める | 価格・納期だけでなくセキュリティを評価項目に入れる |
| 調達の流れ | 5 契約 | 責任範囲、報告義務、監査受入れ、終了時のデータ消去を定める | 委託しても責任は委託元に残り、監督義務がある |
| 分析手法 | SWOT分析 | 強み・弱み・機会・脅威の4区分で整理する | 自社の弱みとしてセキュリティ人材不足などを可視化できる |
| 分析手法 | 3C分析 | 顧客・競合・自社の視点で市場環境を捉える | 取引先が求めるセキュリティ水準を知る手掛かりになる |
| 分析手法 | PPM | 市場成長率と市場占有率で事業を4分類し資源配分を考える | 投資の優先順位づけの考え方はセキュリティ投資にも通じる |
| 分析手法 | KGI/CSF/KPI | 最終成果指標・重要成功要因・中間指標で目標を管理する | 訓練開封率や脆弱性修正日数をKPIとして経営層に報告できる |
| 経営の役割 | CISO | 情報セキュリティの最高責任者 | 方針決定・インシデント時の指揮・経営層への報告を担う |
| 経営の役割 | CIO | 情報システム全体の最高責任者 | 情報システム戦略を経営戦略と整合させる |
| 経営の役割 | 内部統制・職務分掌 | 申請・承認・実行・記録を分けて相互に牽制する | 1人で完結させないことで不正が起きにくい構造をつくる |
| 生成AIの留意点 | ハルシネーション | 事実でない内容をもっともらしく出力する | 出力をそのまま使わず、人が必ず事実確認を行う |
| 生成AIの留意点 | 入力情報の漏えい | 入力内容が保存・学習に使われる場合がある | 個人情報や未公表の経営情報の入力を禁止し、承認済みサービスに限定する |
| 生成AIの留意点 | 著作権など権利 | 生成物が既存の著作物に類似する場合がある | 公表・商用利用の前に権利関係と利用規約を確認する |
- CISO
- 最高情報セキュリティ責任者。情報セキュリティ方針の策定、リスク対応方針の決定、インシデント時の指揮、経営層や社外への報告に責任を負う経営層の役職。情報システム全体に責任を持つCIOとは役割が異なる。
- コーポレートガバナンス
- 経営者が適切に経営を行っているかを、株主など外部の視点も入れて監督する企業統治の仕組み。社外取締役や監査役の設置、適切な情報開示などによって実現する。
- 内部統制
- 業務の有効性・効率性、財務報告の信頼性、法令等の遵守、資産の保全を達成するために組織へ組み込む仕組み。整備・運用の責任は経営者にあり、職務分掌や承認手続、記録の保存が具体策となる。
- 損益分岐点
- 売上高と費用が等しくなり、利益がちょうどゼロになる売上高。費用を変動費と固定費に分けて求める。セキュリティ投資の説明でも、費用と、事故時に見込まれる損失を比べる考え方が土台になる。
- セキュリティ投資の費用対効果
- 対策にかかる年間費用と、対策によって減らせる想定損失額(発生確率×1回あたりの損失)を比較して投資の妥当性を判断する考え方。ただし人命や法令遵守に関わるものは費用対効果だけで決めない。
- EA(エンタープライズアーキテクチャ)
- 組織の業務とシステムの全体像を、ビジネス・データ・アプリケーション・技術の各体系で描き、現状と理想を対比して移行計画を立てる手法。全体最適の観点から情報システムを整理する。
- DX
- データとデジタル技術を活用して、製品・サービスやビジネスモデル、業務・組織を変革し、競争上の優位を確立すること。単なる電子化ではなく変革を指す。扱うデータと外部接続が増えるため、セキュリティ確保が前提となる。
- RFI(情報提供依頼書)
- 調達の初期段階で、市場にどのような製品・サービス・技術があるかの情報提供をベンダに依頼する文書。ここで得た情報をもとに要件を整理し、次の段階でRFPを作成する。
- RFP(提案依頼書)
- システムに求める機能・性能・予算・納期・体制・セキュリティ要件などを示し、ベンダに具体的な提案を依頼する文書。RFIの後に作成し、提出された提案書を評価基準に沿って比較して発注先を選ぶ。
- SWOT分析
- 内部環境の強み・弱みと、外部環境の機会・脅威の4区分で自社の状況を整理する分析手法。顧客・競合・自社で市場を見る3C分析、市場成長率と占有率で事業を分類するPPMなどと使い分ける。
- KGI/CSF/KPI
- KGIは最終的に達成すべき成果指標、CSFはその達成に決定的に重要な成功要因、KPIは進捗を測る中間指標。セキュリティでも、訓練の開封率や脆弱性の平均修正日数などをKPIとして経営層に示せる。
- ハルシネーション
- 生成AIが、事実に基づかない内容をもっともらしい文章として出力する現象。出力をそのまま正しいものとして扱わず、必ず人が事実確認を行ってから業務に用いる必要がある。
例題 新しい業務システムを外部に発注する。RFIとRFPはどちらを先に出すか。
RFI(情報提供依頼書)が先。まずRFIで市場にどのような製品・サービス・技術があるかの情報を集め、その情報をもとに要件を整理してからRFP(提案依頼書)を作成し、ベンダに具体的な提案を依頼する。順序はRFI→RFP→提案書の受領→評価・選定→契約。RFPにはセキュリティ要件を必ず明記する。
例題 議事録の要約に生成AIを使いたい。どのような点に注意すべきか。
第一に、議事録に含まれる個人情報や未公表の経営情報をそのまま入力しない。入力内容が保存・学習に使われて外部へ流出する恐れがあるため、組織が承認したサービスに限定し、入力してよい情報の範囲をルールで定める。第二に、生成された要約はハルシネーションを含む可能性があるので、必ず人が原文と突き合わせて確認してから確定させる。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目A ストラテジ系(経営・組織論、業務分析、会計・財務、システム戦略、システム企画、経営戦略手法)
情報資産とリスクの実務
情報資産を洗い出す・台帳をつくる
何を情報資産として数え、台帳にどの項目を書き、いつ更新するのか。業務部門の目線で漏れのない洗い出し方を身につけます。
情報セキュリティの取組みは、守る対象を数え上げるところから始まります。守る対象がはっきりしなければ、どこにどれだけコストをかけるかを決められないからです。この数え上げが情報資産の洗い出しであり、その結果をまとめたものが情報資産台帳です。台帳は「作って終わり」の書類ではなく、リスクアセスメント、アクセス権の設計、教育の対象決め、監査、インシデント発生時の影響範囲の把握まで、あらゆる場面で参照される土台になります。
情報資産に含まれるのは電子データだけではありません。顧客データベースや提案書のような電子データ、契約書や申込書のような紙の書類、ノートPC・スマートフォン・複合機・USBメモリのような機器、業務で使うソフトウェアやライセンス、クラウドサービスや外部委託のような外部サービス、そしてベテラン社員だけが知っているノウハウのような人が持つ知識まで、業務上の価値があるものはすべて対象です。自社が所有しているかどうかは基準になりません。クラウド上に置いた情報も、顧客から預かった情報も、自社が責任をもつ情報資産です。
台帳に書く項目は組織によって違いますが、最低限そろえたいのは、資産名、利用部門、管理責任者、保管場所、媒体(電子/紙/機器)、件数または量、機密性・完全性・可用性の評価値、そこから決まる重要度です。ここで大切なのは、管理責任者を必ず個人の役職まで特定することです。「営業部全員」や「担当者」といった書き方では、いざというときに誰が判断するのかが決まりません。件数も「不明」のままにせず、概数でよいので把握します。件数が分からない資産は、そもそも管理が及んでいないというサインです。
難しいのが、部署をまたいで使われる情報の管理責任者です。営業部が入力した顧客情報を物流部が配送に使い、経理部が請求に使い、情報システム部がサーバを運用している、という状態はよくあります。このとき、システムを運用している情報システム部は「預かって動かしている側」であって、情報の中身に責任をもつ立場ではありません。原則は、その情報を業務上生み出し、内容の正しさと利用範囲に責任をもつ業務所管部門の責任者を管理責任者とし、ほかの部門は利用部門として台帳に併記することです。連名にしたり空欄にしたりすると、責任の所在があいまいになります。
台帳は実態と合っていて初めて意味があります。年次の棚卸しだけに頼ると、実態とのずれが最大で1年間放置されます。新しい業務やサービスを始めたとき、人事異動や退職で担当者が変わったとき、システムを更改したとき、保管場所を変えたときなど、資産に変化があった時点で随時更新し、加えて年に一度は全体を棚卸しして抜けを埋める、という二段構えが基本です。更新のきっかけを規程に書いておくと、担当者が変わっても運用が続きます。
洗い出しでよく漏れるものには決まった型があります。部員の貸与PCのデスクトップに置かれた個人作業用のファイル、申請せずに使い始めた無料のクラウドストレージやアンケートサービス、退職者から引き継がれないまま残ったUSBメモリや共有アカウント、机の引出しにたまった紙の申込書や受領した名刺、テスト用に本番データをコピーした検証環境などです。これらはアンケートによる自己申告では出てきません。実地の確認、共有フォルダやクラウドサービスの利用状況の確認、退職・異動時のチェックリストを組み合わせて拾い上げます。
情報資産台帳の記載例(A社営業部・抜粋)
No 資産名 利用部門 管理責任者 保管場所 媒体 件数 機密 完全 可用 重要度 1 顧客連絡先一覧 営業部/物流部 営業部長 販売管理サーバ 電子 8,400 高 中 高 高 2 契約書原本 営業部 営業事務課長 3階書庫(施錠) 紙 1,200 高 高 中 高 3 受領した名刺 営業部 営業企画課長 名刺管理サービス 電子 5,600 中 低 低 中 4 見積書ひな形 営業部 営業企画課長 部門共有フォルダ 電子 40 低 中 低 中 5 貸与ノートPC 営業部 情報システム部長 各担当者 機器 32 高 中 中 高 6 展示会案内文 営業部 営業企画課長 部門共有フォルダ 電子 12 低 低 低 低
| 区分 | 項目 | 書き方の例 | よくある不備 |
|---|---|---|---|
| 識別 | 資産名 | 顧客連絡先一覧(販売管理システム) | 「顧客データ」など範囲が分からない書き方 |
| 識別 | 媒体 | 電子/紙/機器 | 電子と紙が混在する資産を1行にまとめてしまう |
| 識別 | 件数・量 | 8,400件/1,200冊/32台 | 「不明」「多数」のまま放置する |
| 責任 | 管理責任者 | 営業部長(氏名まで特定) | 「営業部全員」「担当者」と書く/連名にする |
| 責任 | 利用部門 | 営業部・物流部・経理部 | 実際に使っている他部門を書き漏らす |
| 所在 | 保管場所 | 販売管理サーバ/3階書庫(施錠) | 「社内」「各自」など特定できない書き方 |
| 評価 | 機密性・完全性・可用性 | 高/中/低の3段階 | 担当者ごとに基準が違うまま評価する |
| 評価 | 重要度 | 3つの評価値から社内ルールで決定 | 評価値と重要度の関係が決まっていない |
| 維持 | 更新のきっかけ | 新規業務・異動・システム更改・年次棚卸し | 年次棚卸しのときしか更新しない |
- 情報資産
- 組織にとって価値があり守るべき対象。電子データ、紙の書類、ハードウェア、ソフトウェア、外部サービス、人が持つノウハウまで含む。所有しているかどうかではなく、業務上の価値と責任の有無で判断する。
- 情報資産台帳
- 情報資産を一覧にした管理表。資産名・利用部門・管理責任者・保管場所・媒体・件数・評価値・重要度などを記録する。リスクアセスメントやアクセス権設計、インシデント時の影響範囲の把握の土台になる。
- 管理責任者
- その情報資産の取扱いについて判断し責任を負う個人。役職まで特定して台帳に記載する。部門をまたぐ資産では、情報を業務上生み出し内容に責任をもつ業務所管部門の責任者を充てるのが原則。
- 利用部門
- その情報資産を業務で使っている部門。管理責任者とは別の欄として台帳に記載し、複数部門が使う場合はすべて書く。影響範囲の把握や周知先の特定に使う。
- 棚卸し
- 台帳の記載と現物・現状を突き合わせ、追加・変更・廃棄を反映する作業。年1回など定期に行うほか、業務変更・異動・システム更改など変化があった時点で随時更新することが望ましい。
- シャドーIT
- 従業員や部門が組織の承認を得ずに業務で使っているIT機器やクラウドサービス。無料のオンラインストレージやアンケートサービスが典型例で、台帳から漏れやすく、安全管理措置も確認されていない。
- 媒体
- 情報が保存されている形態。電子(サーバ・PC・クラウド・可搬媒体)、紙、機器などに区分する。媒体によって保管方法、持出し方法、廃棄方法が変わるため台帳に明記する。
- 情報オーナー
- 情報の内容と利用範囲に責任をもつ立場。システムを運用するシステム管理者とは役割が異なり、公開範囲やアクセス権の可否、廃棄の判断を行うのは情報オーナー側である。
例題 営業部が入力した顧客情報を、物流部が配送に、経理部が請求に使っている。サーバは情報システム部が運用している。管理責任者は誰にすべきか。
情報を業務上生み出し、内容と利用範囲に責任をもつ営業部の責任者を管理責任者とする。情報システム部はサーバを運用する立場であって情報の内容に責任をもつわけではない。物流部・経理部・情報システム部は利用部門または運用部門として台帳に併記する。連名や空欄にすると判断者が決まらない。
例題 部内アンケートで洗い出したところ、共有フォルダとサーバの情報しか挙がらなかった。ほかに確認すべきものは何か。
貸与PCのローカルに置かれたファイル、申請せずに使っているクラウドサービス、退職者から引き継いだUSBメモリや共有アカウント、引出しの紙の申込書や名刺、本番データをコピーした検証環境などである。自己申告では出てこないため、実地確認と利用状況の確認を併用する。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目B 情報資産管理/JIS Q 27001(情報セキュリティマネジメントシステム-要求事項)
重要度を決めて格付けする
機密性・完全性・可用性を3段階で評価し、その結果から重要度を決め、格付けに応じた取扱いルールにつなげる考え方を学びます。
洗い出した情報資産は、すべてを同じ強さで守ることはできません。限られた人手と費用を配分するために、資産ごとに重要度を決めます。重要度の土台になるのが、機密性・完全性・可用性の3つの観点からの評価です。実務では高・中・低の3段階(数値なら3・2・1)を使うことが多く、段階の数を増やすほど判断に迷い、評価が担当者ごとにぶれやすくなります。
3つの観点は、それぞれ「損なわれたときに何が起きるか」で評価します。機密性は、その情報が漏えいしたときの影響で見ます。法令上の報告義務や損害賠償が生じる、取引先との信頼を失う、価格交渉で不利になる、といった影響が大きいほど評価値は高くなります。完全性は、内容が誤って書き換えられたり壊れたりしたときの影響で見ます。誤った金額の見積を出す、誤った先に出荷する、決算が誤るといった業務への波及が大きいほど高くなります。可用性は、使えなくなったときの影響で見ます。何時間・何日止まると業務が止まるか、代替手段があるかで判断します。
3つの評価値から重要度を決めるルールは、あらかじめ組織として決めておく必要があります。よく使われるのは最大値方式で、機密性・完全性・可用性のうち最も高い評価値をその資産の重要度とします。たとえば機密性が中、完全性が高、可用性が高の資産は重要度「高」になります。最大値方式が広く使われるのは、どれか1つでも損なわれれば重大な影響が出る、という情報セキュリティの考え方に合っているからです。合計値や平均値を使う方式もありますが、平均を採ると1つだけ突出して高い観点が薄まってしまう点に注意が必要です。いずれにせよ、方式が決まっていないと部門ごとに結果がばらつきます。
重要度を決めるのは目的ではなく手段です。決めた重要度(格付け)ごとに、保管・持出し・共有・複製・廃棄の取扱いルールを対応づけて初めて意味が生まれます。たとえば重要度が高なら施錠書庫または暗号化しての保管、持出しは上長承認、社外共有は秘密保持契約と部門長承認、廃棄は溶解またはデータ消去の記録を残す、といった具合です。低の資産にまで同じ手続を課さないことが、ルールを守り続けられるかどうかを分けます。
評価は高すぎても低すぎても害があります。過大評価をすると、公開済みのカタログや案内文にまで承認や暗号化を課すことになり、手続が多すぎて現場が回らなくなります。その結果、承認が中身を見ない形式的な押印になり、本当に守るべき情報の承認も素通りしてしまいます。逆に過小評価をすると、実際には個人情報や取引条件を含む情報が誰でも編集できる共有フォルダに置かれ、漏えいしても気づかない状態が生まれます。営業日報や打合せメモのように「社内の書類だから」と軽く扱われがちなものほど、中身を見て評価し直す価値があります。
評価のばらつきを抑えるには、段階の名前をそろえるだけでは足りません。部門ごとに「重要・普通・軽微」「A・B・C」「1〜5」と表記が違うのはもちろん問題ですが、より本質的なのは、その段階に当てはめるための判断基準を全社共通の言葉で書くことです。「漏えいすると法令上の報告義務や損害賠償が生じるおそれがある情報は機密性を高とする」「1営業日以上使えないと出荷が止まる情報は可用性を高とする」のように、具体的な影響で基準を書けば、誰が評価しても近い結果になり、部門をまたいだ優先順位づけができるようになります。
評価値から重要度を決め、取扱いルールに結び付けた例(最大値方式)
区分 機密性 完全性 可用性 重要度 取扱いの例 顧客連絡先一覧 高 中 高 高 施錠保管/持出し上長承認/社外共有は契約と部門長承認 契約書原本 高 高 中 高 施錠書庫/複製禁止/廃棄は溶解と記録 受領した名刺 中 低 低 中 施錠保管/持出し上長承認/廃棄は溶解 見積書ひな形 低 中 低 中 部門内共有可/改訂は責任者承認 展示会案内文 低 低 低 低 制限なし/一般廃棄可
| 区分 | 段階 | 判断の目安 | 対応する扱い |
|---|---|---|---|
| 機密性 | 高 | 漏えいすると法令上の報告義務・損害賠償・取引停止のおそれがある | 施錠保管または暗号化/社外共有は契約と部門長承認 |
| 機密性 | 中 | 漏えいすると社内の業務や信用に一定の影響が出る | 施錠保管/持出しは上長承認 |
| 機密性 | 低 | 公開済み、または漏えいしても実害がない | 制限なし |
| 完全性 | 高 | 誤りがあると誤請求・誤出荷・決算誤りなど後続業務が破綻する | 更新権限の限定/変更履歴の保存 |
| 完全性 | 中 | 誤りがあると手戻りが生じるが業務は継続できる | 責任者の承認による改訂 |
| 完全性 | 低 | 誤っても影響が軽微で容易に直せる | 特段の制限なし |
| 可用性 | 高 | 1営業日未満の停止でも業務が止まり代替手段がない | 冗長化/バックアップからの復旧手順を整備 |
| 可用性 | 中 | 数日の停止なら代替手段で業務を継続できる | 定期バックアップ |
| 可用性 | 低 | 1週間以上使えなくても業務に大きな支障がない | 通常のバックアップのみ |
| 重要度 | 決め方 | 3つの評価値のうち最大の値をその資産の重要度とする(最大値方式) | 重要度ごとに保管・持出し・共有・廃棄のルールを適用 |
- 機密性の評価
- その情報が漏えいしたときの影響の大きさで決める評価。法令上の報告義務や損害賠償、取引先の信頼喪失、競争上の不利などの大きさを判断材料にする。個人情報や取引条件を含む情報は高くなりやすい。
- 完全性の評価
- その情報が誤って書き換えられたり壊れたりしたときの影響の大きさで決める評価。誤った金額での請求、誤った先への出荷、決算の誤りなど、後続業務への波及が大きいほど高くする。
- 可用性の評価
- その情報が使えなくなったときの影響の大きさで決める評価。どのくらいの時間止まると業務が止まるか、代替手段があるかで判断する。件数の多さではなく業務停止の影響で決める点が重要。
- 最大値方式
- 機密性・完全性・可用性の3つの評価値のうち最も高い値をその資産の重要度とする決め方。どれか1つでも損なわれれば重大な影響が出るという考え方に沿うため広く使われる。
- 格付け(分類)
- 決定した重要度に応じて情報資産を区分し、区分ごとに保管・持出し・共有・複製・廃棄の取扱いルールを定めること。極秘・社外秘・公開といったラベルを使う組織もある。
- 評価基準
- 高・中・低のどれに当てはめるかを判断するための共通のものさし。「漏えいすると法令上の報告義務が生じる情報は高」のように具体的な影響で書き、全社で共有する。
- 過大評価
- 実際の影響より高く評価すること。過剰な手続で現場が回らなくなり、承認が形骸化して本来守るべき情報の管理まで緩む。公開情報にまで高い格付けを与えていないか点検する。
- 過小評価
- 実際の影響より低く評価すること。個人情報や取引条件を含む情報が保護されないまま扱われ、漏えいしても検知できない状態を生む。日報や打合せメモなど日常の文書で起きやすい。
例題 顧客ごとの値引き率を記載した価格表がある。漏れると価格交渉で不利になる。誤って書き換わると誤った金額で見積を出す。半日使えなくても前月の紙の控えで代替できる。評価はどうなるか。
機密性 高、完全性 高、可用性 低となる。最大値方式なら重要度は高。可用性は件数や使用頻度ではなく、使えなくなったときに業務が止まるか、代替手段があるかで判断する点に注意する。
例題 ほぼすべての資産が「機密性 高」と評価され、公開済みのカタログの持出しにも上長承認が必要になった。何が問題か。
過大評価による手続の過剰で、承認が中身を見ない形式的なものになり、本当に守るべき情報の承認まで素通りする。対処は承認の廃止ではなく、影響の大きさで書いた評価基準を示して評価をやり直し、公開情報の評価値を実態に合わせて下げることである。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目B 情報資産管理/JIS Q 27002(情報セキュリティ管理策の実践のための規範)
リスクアセスメントを回す
リスク特定・分析・評価の3工程で優先順位をつけ、回避・移転・低減・受容から対応を選び、残留リスクを承認して回し続ける流れをつかみます。
リスクアセスメントは、リスク特定・リスク分析・リスク評価の3つの工程からなります。リスク特定は、どんな悪いことが起こりうるかを洗い出す工程です。情報資産台帳を出発点に、それぞれの資産に対する脅威(不正アクセス、内部不正、紛失、故障、災害など)と、その脅威につけ込まれる脆弱性(退職者IDの放置、暗号化されていないPC、持出し記録がない、教育不足など)を組み合わせ、「この資産にこの脅威がこの弱点を突いて起きる」という形で具体的に書き出します。ここで対策を考え始めたり費用を見積もり始めたりするのは早すぎます。
リスク分析は、洗い出したリスクの大きさを見積もる工程です。実務でよく使うのは、発生可能性と影響度をそれぞれ高・中・低(3・2・1)で評価し、積または表で組み合わせてリスクレベルを出す方法です。金額で見積もる定量的な方法もありますが、業務部門では判断しやすい段階評価がまず使われます。大切なのは、部門ごとに違う勘で点数を付けないことで、そのためにも評価基準を全社で共通にしておきます。
リスク評価は、算出したリスクレベルをあらかじめ決めた受容基準と比べ、対応が必要かどうかと優先順位を決める工程です。受容基準は「リスクレベル6以上は受容できない」のように数値で決めておきます。基準を先に決めずに結果を見てから線を引くと、対策したくないリスクを基準の下に置く、といった恣意的な運用になりかねません。
対応が必要と判断したリスクには、回避・移転・低減・受容(保有)の4つから対応を選びます。回避はリスクの原因となる活動そのものをやめることで、たとえば展示会での名刺収集をやめる、その業務から撤退する、といった選択です。移転(共有)は保険への加入や契約による責任分担で、損害の一部を他者に移す方法です。低減はアクセス権の見直しや暗号化、手順の追加などで発生可能性や影響度を下げる方法で、実務で最も多く使われます。受容は、対策の費用が見合わないなどの理由でリスクを受け入れ、そのまま持ち続ける判断です。受容は「何もしない」ことと同じではなく、意思をもって記録に残す判断である点が重要です。
対応を選ぶときは費用対効果を見ます。年間に想定される損害額(想定損害額×年間の発生見込み)に対して、対策費用が大きく上回るなら、その対策は合理的とはいえません。逆に、少額の対策で大きな損害をほぼ防げるなら優先して実施します。対策後に残るリスクが残留リスクで、受容基準を上回る残留リスクをそのままにする場合は、費用対効果と残るリスクの内容を整理して、責任をもつ管理層(経営陣)の承認を得たうえで記録します。担当者や情報セキュリティリーダーの一存で受容してよいものではありません。
決めた対応はリスク対応計画にまとめます。計画には、対象のリスク、選んだ対応策、責任者、期限、実施後に残る残留リスクの扱いを必ず書きます。責任者や期限が「未定」「できるだけ早く」のままの行は、実行されないまま次のアセスメントを迎えます。そしてアセスメントは一度で終わりません。新しいシステムやサービスを導入したとき、法令が改正されたとき、インシデントが発生したとき、組織体制が変わったときは前提そのものが変わっているため、定期の見直しを待たずに再アセスメントを行います。この繰り返しがマネジメントシステムのPDCAそのものです。
リスク分析・評価とリスク対応方針の例(受容基準:積が6以上は受容できない)
No 脅威 脆弱性 発生可能性 影響度 積 受容 対応方針 1 退職者IDでの不正閲覧 退職時のID停止が遅い 中(2) 高(3) 6 不可 低減:退職手続にID停止を組込み 2 ノートPC紛失 ディスクが暗号化されていない 中(2) 高(3) 6 不可 低減:ディスク暗号化を全台に適用 3 紙の契約書の紛失 持出し記録がない 中(2) 中(2) 4 可 保有:記録を残し年次で再評価 4 展示会案内文の誤送信 宛先確認の手順がない 高(3) 低(1) 3 可 保有:影響が小さく対策せず記録 5 委託先での情報漏えい 委託契約に管理条項がない 中(2) 高(3) 6 不可 移転:契約に賠償条項と保険を追加
| 区分 | 名称 | やること・意味 | 成果物・例 |
|---|---|---|---|
| 工程 | リスク特定 | 資産×脅威×脆弱性で起こりうる出来事を洗い出す | リスク一覧(大きさの見積りはまだ行わない) |
| 工程 | リスク分析 | 発生可能性と影響度を評価してリスクレベルを算出する | リスクレベル(例:可能性3×影響度3=9) |
| 工程 | リスク評価 | 受容基準と比較して対応の要否と優先順位を決める | 優先対応リスト |
| 対応 | リスク回避 | 原因となる活動そのものをやめる | 名刺収集の廃止/該当業務からの撤退 |
| 対応 | リスク移転 | 保険や契約で損害の一部を他者に移す | サイバー保険への加入/委託契約に賠償条項 |
| 対応 | リスク低減 | 管理策で発生可能性や影響度を下げる | アクセス権見直し/暗号化/手順の追加 |
| 対応 | リスク保有 | 受容基準内、または費用が見合わないため受け入れる | 記録を残し年次で再評価 |
| 判断 | 費用対効果 | 年間想定損害額と対策費用を比べる | 想定損害500万円×年0.2件=年100万円 |
| 判断 | 残留リスクの承認 | 基準を上回る残留リスクは管理層が承認する | 経営会議での承認記録 |
| 契機 | 再アセスメント | 前提が変わったら定期見直しを待たずに実施 | 新システム導入/法改正/インシデント/体制変更 |
- リスク特定
- 情報資産に対する脅威と脆弱性を組み合わせ、起こりうる出来事を洗い出す工程。台帳を出発点に「資産×脅威×脆弱性」の形で具体的に書き出す。この段階では大きさの見積りや対策の検討は行わない。
- リスク分析
- 特定したリスクの大きさを見積もる工程。発生可能性と影響度を段階評価して組み合わせる定性的手法と、金額で見積もる定量的手法がある。評価基準を全社で共通化してばらつきを抑える。
- リスク評価
- 算出したリスクレベルをあらかじめ定めた受容基準と比較し、対応の要否と優先順位を決める工程。受容基準は結果を見る前に決めておくことが恣意的な運用を防ぐ鍵になる。
- リスク受容基準
- どの水準までのリスクなら受け入れられるかを組織として定めた線引き。「リスクレベル6以上は受容できない」のように具体的に決め、経営層の承認を得て運用する。
- リスク回避
- リスクの原因となる活動そのものをやめる対応。名刺収集を廃止する、その業務から撤退する、リスクの高いサービスの利用をやめるなど。効果は大きいが事業機会を失う可能性がある。
- リスク移転(共有)
- 保険への加入や契約による責任分担で、損害の一部を他者に移す対応。損害の金銭的な負担は移せても、説明責任や信用の低下まで移せるわけではない点に注意する。
- リスク低減
- 管理策を追加して発生可能性や影響度を下げる対応。アクセス権の見直し、暗号化、手順の追加、教育などが該当し、実務で最も多く選ばれる。実施後も残留リスクは残る。
- リスク保有(受容)
- 対策の費用が見合わないなどの理由でリスクをそのまま受け入れる判断。何もしないこととは異なり、判断の理由と承認を記録に残し、定期的に見直す必要がある。
- 残留リスク
- リスク対応を実施した後になお残るリスク。受容基準を上回る残留リスクを受け入れる場合は、費用対効果と内容を整理して責任をもつ管理層の承認を得たうえで記録する。
- リスク対応計画
- 選んだ対応策、責任者、期限、残留リスクの扱いをまとめた実行計画。責任者と期限が定まっていない行は実行されないため、必ず個人と日付まで決める。
- 再アセスメント
- 前提が変わったときにリスクアセスメントをやり直すこと。新システムやサービスの導入、法令改正、インシデントの発生、組織体制の変更などが契機となり、定期見直しを待たずに実施する。
例題 低減策を実施しても受容基準をわずかに上回るリスクが残った。追加対策の費用は年800万円、想定損害額は年100万円である。どうすべきか。
費用が損害額を大きく上回るため追加対策は合理的でない。費用対効果と残るリスクの内容を整理し、責任をもつ管理層に説明して残留リスクとして承認を得たうえで記録する。担当者やリーダーの一存で受容したり、計算方法を変えて基準内に見せかけたりしてはならない。
例題 年1回のアセスメントを4月に実施した。その後、新しいクラウドサービスの導入、法令改正、他部門でのインシデント、組織統合があった。次回まで待ってよいか。
待ってはならない。いずれもアセスメントの前提が変わる出来事であり、その都度リスクを見直す必要がある。定期の実施は最低限の頻度であって、変化があったときの再アセスメントを代替するものではない。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目B リスクアセスメント/JIS Q 27001・JIS Q 31000(リスクマネジメント-指針)
業務でのIT利用
アカウントとアクセス権の運用
誰に何を触らせるかを決め、その状態を保ち続ける仕事です。付与・変更・削除・点検の流れと、記録の残し方を身につけます。
情報を守る出発点は「その情報に触れられる人を、必要な人だけにする」ことです。これを最小権限の原則といいます。似た考え方に Need-to-Know(知る必要のある人だけが知る)があり、権限だけでなく、会議に誰を呼ぶか、資料を誰に配るかという日常の判断にも当てはまります。業務部門の情報セキュリティリーダーは、システムの設定そのものより「誰にどこまで必要か」を業務の立場から判断し、情報システム部門へ正しく伝える役割を担います。
権限は与えるときの手続だけでなく、変える・消す手続まで決めて初めて回ります。入社時は業務に必要な最小限から始めます。異動時は必ず旧部署の権限を削除してから新部署の権限を付与します。追加だけを繰り返すと、勤続年数の長い人ほど不要な権限を抱える「権限の蓄積」が起き、誤操作や内部不正の被害が大きくなります。退職時は最終出社日までにアカウントを無効化または削除し、貸与端末・ICカード・書類を回収します。退職者のアカウントが有効なまま残っていると、外部の第三者に使われても正規の利用に見えてしまいます。
手続には職務分掌(役割の分離)を組み込みます。権限を申請・承認する人と、実際にシステムへ登録する人を分けるのが基本形です。同じ人が申請から登録まで一人で完結できると、架空のIDを作ったり、自分の権限をこっそり広げたりできてしまいます。分けられない小さな組織では、作業の記録を第三者が事後に点検する形で補います。また、複数人が同じIDを使う共有アカウントは、操作ログを見ても誰がやったか特定できず、責任追跡性(アカウンタビリティ)が失われます。利用者ごとに個人IDを発行するのが原則で、やむを得ず共有する場合は利用者と時間帯の記録を別に残します。
管理者権限のような特権IDは、平常時は誰にも割り当てず、必要な作業のときだけ申請・承認のうえ貸し出し、作業後に返却してパスワードを変更する運用が安全です。貸出記録(誰が・いつ・何のために)とシステム側の操作ログを突き合わせれば、記録にない特権操作を見つけられます。特権IDを常時付与しておくと、日常業務のうっかり操作が致命的な事故になりやすく、事故後の原因究明も難しくなります。
アクセス権の棚卸しは、いま付いている権限の一覧を業務を分かっている人が見て、必要かどうかを判断する作業です。一覧を出すのは情報システム部門でも、要否を判断し承認するのは業務部門の管理者です。半年や1年ごとなど周期を決め、退職者・異動者のIDが残っていないか、業務に不要な権限が付いていないか、長期間使われていないIDがないかを確認し、結果と承認者を記録として残します。棚卸しは「見つけて直す」までを含み、一覧を眺めて終わりでは意味がありません。
パスワードは、短いものを頻繁に変えさせるより、十分な長さのものを使い回さずに使い、漏えいが疑われたときに速やかに変える方が有効だと考えられています。定期変更を強制すると、末尾の数字を1つ増やすだけといった安易な変更を招きがちです。重要な情報を扱う場合や社外から接続する場合は、知識(パスワード)に加えて所持(スマートフォンのアプリ・ワンタイムパスワード)などを組み合わせる多要素認証を検討します。パスワードが漏れても、もう一つの要素がなければ入られないため、リスト型攻撃やフィッシングへの備えになります。
ログは「取る・守る・見る」の三つがそろって役に立ちます。何を取るか(ログイン成功と失敗、権限の変更、重要な情報の参照や持出し)、どれだけ保管するか、誰が点検するかを決めます。ログをそのサーバの中だけに置き、管理者が自由に書き換えられる状態では、その管理者自身の不正の証拠になりません。別の場所へ集約して書換えを防ぎ、点検は作業をした本人ではない人(内部監査担当など)が行うのが原則です。ログを取得していることを従業員に周知しておくと、不正の抑止としても働きます。
最小権限で設計した共有フォルダのアクセス権(根拠を書けない権限は付けない)
共有フォルダ 利用者グループ 権限 設定の根拠 /売上/請求書 経理部 読み書き 請求書を作成し保管する担当 /売上/請求書 営業部 読み取り 自部門の請求状況を確認する /人事/給与 人事部給与担当 読み書き 給与計算を行う担当 /人事/給与 人事部長 読み取り 内容を確認し承認する /共有/社内報 全社員 読み取り 公開してよい社内向け資料 /共有/社内報 広報部 読み書き 記事を作成し掲載する担当
| 区分 | やること | 残す記録 |
|---|---|---|
| 入社・着任 | 業務に必要な最小限の権限だけを付与し、規程とパスワードの扱いを説明する | 申請書、承認者、付与した権限の一覧 |
| 異動 | 旧部署の権限を削除してから新部署の権限を付与する | 削除と付与の申請・承認記録 |
| 退職 | 最終出社日までにアカウントを無効化または削除し、端末・ICカード・書類を回収する | 無効化の日時、返却物のチェックリスト |
| 日常(特権ID) | 作業のときだけ申請・承認のうえ貸出し、返却時にパスワードを変更する | 貸出記録(誰が・いつ・何のために)と操作ログ |
| 定期(棚卸し) | 権限一覧を業務部門の管理者が確認し、不要な権限を削除する | 確認日、確認者、承認者、是正した内容 |
| 定期(ログ点検) | ログイン失敗、権限変更、重要情報の参照を、作業者以外が点検する | 点検日、点検者、気づいた事象と対応 |
- 最小権限の原則
- 利用者やプログラムに、業務を行うために必要な最小限の権限だけを与える考え方。余分な権限は誤操作や不正の被害を広げるため、付与時だけでなく異動や棚卸しのたびに見直して削る。
- Need-to-Know
- 知る必要のある人だけが情報を知るという原則。システムの権限設定だけでなく、会議の出席者、資料の配付先、メールの宛先を決めるときの判断基準としても使う。
- 職務分掌(役割の分離)
- 一人の担当者が申請から承認、実行までを完結できないように役割を分けること。権限の申請者と承認者、登録作業者を分けるのが典型で、分離できない場合は第三者による事後点検で補う。
- 共有アカウント
- 複数人が同じIDとパスワードを使う運用。誰が操作したかをログから特定できず責任追跡性が失われる、退職者が使い続けられるなどの問題があり、原則として個人IDに置き換える。
- 特権ID
- 設定変更や全データの参照ができる管理者用のID。平常時は割り当てず、作業のたびに申請・承認・貸出・返却とパスワード変更を行い、貸出記録と操作ログを突き合わせて点検する。
- アクセス権の棚卸し
- 付与済みの権限一覧を定期的に業務部門の管理者が確認し、不要な権限や退職者・異動者のIDを見つけて削除する作業。誰がいつ確認し承認したかを記録に残すところまでが範囲。
- 責任追跡性(アカウンタビリティ)
- ある操作を誰が行ったかを後から追跡できる性質。個人ごとのIDとログの取得によって成り立ち、共有アカウントやログの未取得があると失われる。
- 多要素認証(MFA)
- 知識(パスワード)・所持(スマートフォン、ICカード)・生体(指紋、顔)のうち異なる二つ以上を組み合わせる認証。パスワードが漏れただけでは侵入されないため、社外からの接続などで有効。
例題 退職者のアカウントを「パスワードを変えて残す」対応にしている。何が問題か。
誰も使えないつもりでも、アカウントが有効である限りログイン試行の対象になり、棚卸しでも「在籍者不明のID」として毎回判断を迷わせる。退職日をもって無効化または削除し、監査のために必要なのはアカウントではなくログと記録である点を押さえる。
例題 部署に管理者IDが1つあり、5人の担当者が共有して日常業務にも使っている。改善の順序は。
まず日常業務を個人IDへ切り替え、管理者IDは通常業務から切り離す。次に管理者IDを平常時は割り当てない運用にし、必要時のみ申請・承認・貸出・返却とパスワード変更を行う。最後に貸出記録と操作ログを突き合わせる点検を定期化する。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目B 業務でのIT利用における情報セキュリティ確保/JIS Q 27002(アクセス制御、ログ取得と監視)/IPA 組織における内部不正防止ガイドライン
クラウドとテレワークで気をつけること
会社の外に情報が出ていく働き方で、どこまでが自社の責任かを見極め、共有設定・端末・回線の穴をふさぎます。
クラウドサービスを使うとき最初に確認するのは、提供者と利用者のどちらが何を守るのかという責任分界です。SaaS であれば、設備・OS・アプリケーションの管理は提供者が担いますが、利用者IDの登録と削除、権限や共有範囲の設定、そこに置くデータの中身は利用者の責任として残ります。「クラウドにしたから安全」ではなく、「自社が担う部分が明確になった」と捉えるのが正しい理解です。自社の責任部分は、社内システムと同じように棚卸しと点検の対象にします。
サービスを選ぶときは、認証の仕組み(多要素認証に対応しているか)、利用者の操作ログを取得して自社で確認できるか、バックアップの範囲と復旧の手順、データの保存場所(国内か国外か。国外なら現地の法令が及ぶ)、そして契約終了時にデータを返却してもらえるか・確実に消去してもらえるかを確認します。特に契約終了時の扱いは、乗り換えを決めてから慌てて調べても遅く、契約前に文書で確認しておく必要があります。無料サービスは、入力した情報の二次利用や、いつサービスが終わるか分からない点にも注意します。
クラウドで最も多い事故は、攻撃ではなく共有設定の誤りです。ファイルを社外の相手に渡すため「リンクを知っている全員が閲覧可」に設定し、そのまま放置すると、リンクが転送されたり検索に載ったりして、意図しない相手に読まれます。対策は、既定の共有範囲を「指定した相手のみ」にしておくこと、社外へのリンク作成を申請・承認制にすること、有効期限を必ず設定すること、そして共有中のファイルを定期的に一覧で点検することです。渡す相手を指定して認証させる方式なら、誰がいつ開いたかの記録も残ります。
会社が把握していない機器やサービスを業務に使うことをシャドーITといいます。無料のファイル変換サイトや翻訳サイト、個人のオンラインストレージやチャットが典型で、多くは悪意ではなく「業務が回らないから」始まります。頭ごなしに禁止しても地下に潜るだけなので、まず利用実態を把握し(プロキシのログや聞き取り)、業務上の必要性を認めたうえで、安全な正規のサービスを用意して規程に位置づけるのが実効的です。私物端末の業務利用(BYOD)も同じで、認める条件(画面ロック、MDMの導入、遠隔消去への同意、業務データを端末に残さない)を定め、申請・承認した端末に限って許可します。
テレワークでは、社内では当たり前だった前提が崩れます。自宅のルータは初期パスワードのままかもしれず、公衆Wi-Fi は通信をのぞかれるおそれがあります。社内システムへはVPNなど暗号化された経路で接続し、公衆Wi-Fi を使うときも同様とします。カフェや新幹線では背後からののぞき見(ショルダーハッキング)に備えてのぞき見防止フィルタを使い、離席時は必ず画面をロックします。自宅でも、家族と共用のPCに業務データを置かない、Web会議で画面共有するときは他のウィンドウや通知を出さない、会議の録画は必要性を確認し保存先と共有範囲を限定する、といった配慮が要ります。
持ち出す端末は、失くす前提で備えます。画面ロックと暗号化を有効にし、MDM(モバイルデバイス管理)で遠隔ロックと遠隔消去ができるようにしておけば、紛失しても被害を小さくできます。重要なのは速さで、紛失や置き忘れに気づいた時点で(確実に失くしたと確かめる前に)定められた窓口へ報告し、遠隔ロックとアカウントの停止を依頼します。自分で探してから報告するという判断が、被害を広げます。
クラウドストレージの共有設定を点検する観点
点検項目 望ましい状態 確認の頻度 既定の共有範囲 指定した相手のみ 設定変更のつど 社外への共有リンク 申請・承認済みのものだけ 月1回 共有リンクの有効期限 必ず設定(無期限は不可) 月1回 編集権限を持つ社外の相手 業務上必要な相手だけ 月1回 退職者・異動者のアカウント 無効化済み 異動・退職のつど 管理者権限を持つ利用者 必要最小限の人数 四半期に1回
| 区分 | 起こりがちな事故 | 打つ手 |
|---|---|---|
| クラウド(選定) | 契約終了時にデータを取り出せない、保存先が国外だと後で分かる | 認証・ログ・バックアップ・データの所在・返却と消去を契約前に確認する |
| クラウド(共有設定) | 『リンクを知っている全員が閲覧可』のまま放置し外部に拡散 | 既定を『指定した相手のみ』にし、社外リンクは申請制+有効期限+定期点検 |
| シャドーIT | 無料の変換サイトに顧客ファイルをアップロード | 利用実態を把握し、必要性を認めて安全な正規サービスを用意する |
| テレワーク(回線) | 公衆Wi-Fiから暗号化せずに社内システムへ接続 | VPNなど暗号化された経路を必須にし、自宅ルータの設定も点検する |
| テレワーク(場所) | のぞき見、家族との共用PCへの業務データ保存、会議の録画の流出 | のぞき見防止フィルタ、画面ロック、貸与端末の使用、録画の保存先と共有範囲の限定 |
| モバイル端末 | 外出先での紛失・置き忘れ | 画面ロックと暗号化、MDMによる遠隔ロック・消去、気づいた時点での即時報告 |
- 責任分界(責任共有)
- クラウドで、提供者が守る範囲と利用者が守る範囲を分ける考え方。SaaSでも利用者IDの管理、権限と共有範囲の設定、預けるデータの内容は利用者の責任として残る。
- 共有リンク
- クラウドストレージのファイルにURLでアクセスさせる仕組み。『リンクを知っている全員が閲覧可』にすると転送だけで拡散するため、相手を指定した共有と有効期限の設定を基本とする。
- シャドーIT
- 会社が把握・承認していない機器やサービスを業務に使うこと。無料の変換・翻訳サイト、個人のストレージやチャットが典型。実態把握と正規の代替手段の提供で減らす。
- BYOD
- 私物端末を業務に使うこと。認める場合は画面ロック、MDMの導入、遠隔消去への同意、業務データの保存範囲などの条件を規程に定め、申請・承認した端末に限って許可する。
- MDM(モバイルデバイス管理)
- スマートフォンやPCを組織側から管理する仕組み。設定の強制、アプリの制限、位置の確認、遠隔ロックと遠隔消去ができ、紛失時の被害を抑える。
- ショルダーハッキング
- 背後や隣からのぞき見て、画面の内容やパスワードの入力を盗み見る行為。カフェ、電車、コワーキングスペースで起きやすく、のぞき見防止フィルタと座る位置の工夫で防ぐ。
- データの所在
- 預けたデータが物理的にどの国に保存されるか。保存先の国の法令が及ぶため、個人情報や機微な情報を扱う場合は契約前に確認し、必要なら国内保存を条件にする。
- 契約終了時のデータ返却・消去
- 解約や乗り換えの際に、自社データを使える形式で返却してもらい、提供者側のバックアップを含めて消去されたことを証明書などで確認する取決め。契約前に文書で確認しておく。
例題 取引先へ大きなファイルを渡すため、共有リンクを作って先方の担当者にメールで送った。ここで追加すべき設定は。
共有範囲を『指定した相手のみ』にして受け手に認証させ、有効期限を業務に必要な期間だけに設定する。こうすると転送だけでは開けず、誰がいつ開いたかも記録に残る。渡し終えたら共有を解除するところまでを手順に含める。
例題 外出先でノートPCの入った鞄を置き忘れたかもしれない、と社員から連絡があった。何から行うか。
確実に紛失したかを確かめる前に、定められた窓口へ報告して遠隔ロックとアカウントの停止を依頼する。探して見つかれば解除すればよく、待つことで得られるものはない。並行して、その端末に入っていた情報の種類を洗い出し、報告の要否を判断する。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目B 業務でのIT利用における情報セキュリティ確保/JIS Q 27002(クラウドサービスの利用、テレワーク、モバイル機器)/総務省 テレワークセキュリティガイドライン
日々のやり取りで守る
メール・ファイルの受渡し・紙・来客・SNS・生成AIなど、毎日の何気ないやり取りに潜む漏えいの経路をふさぎます。
情報漏えいの原因として毎年上位に入るのは、攻撃ではなく誤操作と紛失です。中でもメールの誤送信は起こりやすく、社外の複数の相手へTOやCCで一斉送信してメールアドレスを互いに見せてしまう事故、宛先の自動補完で似た名前の別人を選んでしまう事故が典型です。対策は、社外への一斉送信はBCCを使う、宛先の自動補完に頼らずアドレス帳から選ぶ、送信ボタンを押してから数分間は送信を保留する仕組みを入れる、一定件数以上や特定の情報を含む場合は上長の確認を経る、といった仕組み側の工夫を重ねることです。「気をつける」だけでは再発します。
添付ファイルを暗号化ZIPにして、パスワードを直後に別メールで送る運用(いわゆるPPAP)は、長く慣習として使われてきましたが、いまは推奨されません。同じメール経路を使うため、経路を盗み見られていればファイルもパスワードも一緒に取られます。誤送信をしたときも、パスワードのメールを続けて同じ宛先へ送ってしまえば意味がありません。さらに、暗号化されたZIPは受信側のウイルス検査をすり抜けるため、マルウェアの侵入口にもなります。相手を指定できる共有ストレージや、組織間で合意した安全な受渡し手段に切り替えるのが本筋です。
取引先や社内の関係者を装った標的型攻撃メールは、文面が自然で見分けが難しくなっています。あやしいと気づいたときは開かずに窓口へ報告します。もし開いてしまったら、まず端末を有線・無線ともネットワークから切り離し、電源は切らずに(証拠となる情報が消えるおそれがあるため)定められた窓口へすぐ報告します。自分でウイルス対策ソフトを走らせて「大丈夫そうだから報告しない」という判断が最も危険です。同じメールを他の人に転送して注意喚起するのも、被害を広げるので避け、窓口から正式に周知してもらいます。開いた人を責めない文化が、早い報告を生みます。
情報を社外へ出すときは、渡し方と手続の両方を決めます。渡し方は、相手を指定して認証させられるか、有効期限を付けられるか、誰がいつ受け取ったかの記録が残るかで選びます。手続としては、社外への提供は個人の判断で行わず、規程に従って上長や情報管理責任者の承認を得ます。電話やメールで「以前もらった資料をもう一度」と依頼された場合は、なりすましの可能性があるため、依頼者の身元を既知の連絡先で確認し、承認手続を通してから対応します。急かされても、その場で送らないことが大切です。
USBメモリなどの可搬媒体は、小さく失くしやすいうえ、持ち出した後の行方が追えません。原則は「持ち出さない」で、必要なときだけ申請・承認のうえ会社が貸与した暗号化対応の媒体を使い、管理簿に持出し日・情報の種類・返却日を記録します。私物の媒体の使用や、外部から持ち込まれた媒体を業務PCに挿す行為は、マルウェア感染の経路にもなるため禁止するのが一般的です。紙の資料も同じで、机上に放置しない(クリアデスク)、離席時は画面をロックする(クリアスクリーン)、不要になった書類はシュレッダーや溶解処理で廃棄する、といった基本を徹底します。一般ごみへの投棄は、そのまま持ち去られます。
人が出入りする場面にも注意が必要です。来客は受付で記録して入館証を渡し、執務エリアでは社員が同行します。会議室では、前の会議のホワイトボードの記載や机上の資料を必ず消し・片付けてから迎えます。共連れ(社員に続いて認証なしで入る)を防ぐため、扉では一人ずつ認証する習慣をつけます。SNSでは、業務内容の投稿はもちろん、社内で撮った写真の背景にホワイトボードや書類、モニタが写り込む事故が起きています。投稿前に背景を確認し、業務に関わる発信は広報の承認を経るルールにします。
生成AIサービスの業務利用も、入口は同じ「情報を社外に出す行為」です。無料の対話型サービスに顧客名や価格、未公表の計画を貼り付ければ、それは社外のサーバへ情報を渡したことになり、入力内容が学習に使われる設定であれば他の利用者への応答に影響する可能性もあります。禁止一辺倒はシャドーIT化を招くため、入力してよい情報の範囲を規程で定め(機密情報・個人情報は入力しない)、入力データを学習に使わない契約の法人向けサービスを会社として用意し、出力をそのまま使わず必ず人が確認する、という形で使える道を作ります。
社外へメールを送る前のチェック(送信保留の数分間で確認する)
確認の順番 確認すること 見落としたときに起きること 1 宛先は正しい相手か 別人・別会社へ情報が届く 2 社外が複数ならBCCか 取引先のアドレスが相互に漏れる 3 CCに社内の必要な人がいるか 承認や共有の抜けが起きる 4 添付は正しいファイルか 別案件の資料や社内限定資料が渡る 5 添付に不要な情報がないか 非表示の行やシートに個人情報が残る 6 社外提供の承認は済んだか 規程違反となり事後の説明ができない
| 区分 | やりがちな運用 | 望ましい運用 |
|---|---|---|
| メール送信 | 社外の複数宛先をTOやCCに並べる、自動補完で宛先を選ぶ | 社外一斉はBCC、アドレス帳から選択、数分間の送信保留と上長確認 |
| 添付ファイル | 暗号化ZIPを添付し、パスワードを直後に別メールで送る(PPAP) | 相手を指定した共有ストレージで渡し、有効期限とダウンロード記録を残す |
| あやしいメール | 自分でウイルススキャンして問題なければ報告しない | 端末をネットワークから切り離し、電源は切らずに窓口へすぐ報告する |
| 社外への提供 | 過去に実績があるので担当者の判断で送る | 依頼者を既知の連絡先で確認し、規程に従って承認を得てから送る |
| 媒体・紙 | 私物USBメモリで持ち出す、不要な書類を一般ごみへ捨てる | 貸与の暗号化媒体を申請・承認と管理簿つきで使い、書類はシュレッダーや溶解処理 |
| 来客・SNS | 会議室に前の資料を残す、社内の写真をそのまま投稿する | 来客前に片付けて同行し、投稿前に背景を確認し業務関連は広報の承認を得る |
| 生成AI | 無料サービスに議事録や顧客名をそのまま貼り付ける | 入力してよい情報を規程で定め、学習に使わない法人向けサービスを会社が用意する |
- 誤送信対策
- メールを誤った宛先へ送る事故を減らす取組み。社外一斉送信はBCC、自動補完に頼らない宛先入力、数分間の送信保留、添付や宛先数に応じた上長確認などを組み合わせる。
- BCC
- 他の受信者に見えない形で宛先を指定する方法。社外の複数の相手へ同じ内容を送るときに使い、TOやCCに並べてメールアドレスを相互に開示してしまう事故を防ぐ。
- PPAP
- 添付ファイルを暗号化ZIPにし、パスワードを別メールで送る慣習。同じ経路を使うため盗聴や誤送信に無力で、ウイルス検査もすり抜けるため、指定相手への共有ストレージ等へ切り替える。
- 標的型攻撃メール
- 特定の組織や担当者を狙い、取引先や社内を装って送られるメール。開いてしまったら端末をネットワークから切り離し、電源は切らずに窓口へすぐ報告するのが基本行動。
- クリアデスク・クリアスクリーン
- 離席時に机上の書類や媒体を片付けて施錠し、画面をロックする習慣。のぞき見や持ち去り、来客による偶然の閲覧を防ぐ、費用のかからない基本的な物理・人的対策。
- 可搬媒体の持出し管理
- USBメモリや外付けディスクの持出しを申請・承認制とし、会社貸与の暗号化対応媒体に限り、管理簿に持出し日・情報の種類・返却日を記録する運用。私物媒体の使用は禁止するのが一般的。
- 共連れ(ピギーバック)
- 認証した人に続いて、認証せずに扉を通り抜ける行為。入退室の記録が実態と合わなくなるため、一人ずつ認証する習慣や、一人しか通れない扉の設置で防ぐ。
- 生成AIの業務利用ルール
- 入力してよい情報の範囲(機密情報・個人情報は入力しない)、利用してよいサービス(入力を学習に使わない契約の法人向け)、出力を人が必ず確認することなどを定めた社内の取決め。
例題 セミナー案内を取引先30社へ送る。BCCを使う以外に、事故を減らすためにできることは。
宛先を手入力せずアドレス帳のグループから選ぶ、送信保留を有効にする、宛先が一定件数を超える場合は上長の確認を経る、可能なら一斉配信の仕組み(メール配信サービス)を使って個別送信にする。仕組みで防ぐほど、当日の注意力に左右されなくなる。
例題 会議の議事録を無料の生成AIで要約したいと相談された。どう答えるか。
頭から禁止せず、その議事録に顧客名・価格・未公表の計画が含まれるかを確認する。含まれるなら無料サービスへの入力は不可とし、会社が用意した法人向けサービス(入力を学習に使わない契約)を案内する。用意がなければ固有名詞を除いた要約の可否を含め、規程の整備を情報システム部門と検討する。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目B 業務でのIT利用における情報セキュリティ確保/JIS Q 27002(情報の取扱い、クリアデスク・クリアスクリーン、情報の転送)/IPA 情報セキュリティ10大脅威(組織編)
委託先・教育・監査
委託先を管理する
業務を外に出しても、情報を守る責任は自社に残ります。選ぶとき・契約するとき・任せている間の三つの場面で、リーダーが何を確かめるかを整理します。
会社の業務の多くは外部に委託されています。給与計算、名簿の入力、通販の発送、システムの開発と運用、コールセンターなど、自社の情報を外の会社に預ける場面は珍しくありません。ここで最初に押さえるべき原則は、業務を委託しても情報を守る責任は委託元からなくならない、ということです。委託先が起こした漏えいであっても、顧客や社会から見れば情報を預けた会社の事故であり、報告も謝罪も再発防止も委託元が行うことになります。だからこそ、委託先の管理は『先方に任せる』ことではなく『自社が確かめ続ける』ことだと考えます。
委託前にやることは、選定基準にセキュリティを入れることです。価格と納期と技術力だけで選ぶと、安いが管理が甘い委託先を選んでしまいます。選定の時点で、情報セキュリティの体制(責任者が置かれているか、規程があるか、従業者に教育をしているか)、実績(同種の業務の経験、過去の事故の有無と対応)、認証の取得状況(ISMS認証やプライバシーマークなど)、そして再委託を行うかどうかを確認します。認証を持っていることは体制がある目安にはなりますが、自社の委託業務がその認証の範囲に含まれているとは限らないため、範囲まで確かめる必要があります。
契約では、口約束にせず文書に落とします。最低限入れるべきなのは、秘密保持義務、預ける情報の取扱い範囲(目的外に使わない、持ち出さない、複製しない)、再委託の可否と事前の書面による承認、委託元の監査(立入りまたは書面)を受け入れる条項、事故が起きたときの報告義務と報告期限、契約が終わったときのデータの返却または削除とその証明です。特に再委託は、知らないうちに情報が third party へ渡る典型的な入口なので、原則禁止としたうえで事前承認制とし、承認する場合は再委託先にも同等の義務を課すことを条件にします。
任せている間も放置しません。定期的に実施状況の報告を受け、必要に応じて書面での確認(チェックリストへの回答と証跡の提出)や立入りによる確認を行います。報告や確認で問題が見つかったら、是正を依頼し、いつまでに何をするかを約束してもらい、期限が来たら実施されたかを確かめます。ここまでやって初めて『監督している』と言えます。年に一度チェックリストを送って回収するだけで、回答内容を読まずに保管しているのは、記録は残っても監督にはなっていません。
個人データを含む業務を委託する場合は、これが法律上の義務になります。個人情報保護法は、個人データの取扱いを委託するときに、委託元が委託先に対して必要かつ適切な監督を行うことを求めています。具体的には、適切な委託先を選ぶこと、委託契約で安全管理措置を定めること、委託先での取扱状況を把握することの三つが柱です。なお、委託に伴って個人データを渡すことは第三者提供に当たらないため本人の同意は不要ですが、その代わりに監督の義務が重く課されている、という関係を理解しておきます。
クラウドサービスの利用も、実質的には委託と同じ発想で見ます。クラウドでは、事業者が守る範囲と利用者が守る範囲が分かれており、これを責任分界点と呼びます。例えばSaaSでは、データセンターやサーバの管理は事業者が担いますが、利用者アカウントの管理、アクセス権の設定、公開範囲の設定、保存するデータの内容は利用者側の責任です。設定を誤って外部に公開してしまう事故は、この利用者側の範囲で起きます。契約前に、どこまでが事業者の責任かを利用規約とサービス仕様で確認し、自社が担う部分の運用手順を決めてから使い始めます。
事故が起きたときの連絡経路も、契約と同時に決めておきます。委託先の担当者が自社の窓口へ何時間以内に第一報を入れるか、誰が受けるか、休日夜間はどうするかを具体的に書き、担当者の交代があれば更新します。事故のときに『どこへ連絡すればよいか分からない』状態が生まれると、初動が半日遅れ、被害が広がります。委託先から報告を受けたら、自社のインシデント対応体制へつなぎ、公表や本人への連絡といった対外的な対応は委託元が主体となって判断します。
委託先の評価表の例(重み付けとその場での判定基準)
確認項目 重み A社 B社 判定の考え方 -------------------------------------------------------------------- 情報セキュリティ責任者の設置 高 有 有 無なら選定外 規程の整備と従業者教育の実施 高 済 未 未は是正を条件に 本委託業務が認証の適用範囲か 高 範囲内 範囲外 範囲外は要追加確認 再委託の有無と管理方法 高 無 有・不明 不明は承認不可 過去3年の事故と再発防止 中 無 有・報告済 隠さない姿勢を評価 監査受入への同意 高 可 不可 不可は契約困難
| 場面 | 主にやること | 確かめ方の例 |
|---|---|---|
| 委託前(選定) | 選定基準にセキュリティを入れる/体制・実績・認証範囲・再委託の有無を確認 | 確認書やチェックリストへの回答、認証登録証の適用範囲、過去の事故と対応の説明 |
| 契約時 | 秘密保持、取扱い範囲、再委託の事前承認、監査受入、事故報告義務、終了時の返却・削除を明文化 | 契約書の条項の有無を一覧で照合し、欠けている条項は締結前に追加交渉する |
| 委託中 | 定期報告の受領、書面または立入りによる確認、是正の依頼と期限管理 | 報告書の内容を読み込む、証跡(教育記録・アクセス権一覧など)の提出を求める |
| 事故発生時 | 第一報の受領、事実確認、対外対応の主体は委託元が担う | 連絡経路と第一報の期限を契約で定め、担当者交代のたびに更新する |
| 契約終了時 | データの返却または削除、アカウントと入館証の返却、義務の存続の確認 | 削除完了報告書の受領、返却物の一覧照合、秘密保持義務の存続期間の確認 |
- 委託先の監督
- 委託元が委託先の取扱状況を把握し、必要な是正を求める一連の活動。個人データの取扱いを委託する場合は個人情報保護法上の義務であり、適切な委託先の選定・契約による安全管理措置の明確化・取扱状況の把握が柱となる。
- 再委託
- 委託先がさらに別の会社へ業務の一部を任せること。委託元の目の届かない範囲に情報が広がるため、契約では原則禁止のうえ事前の書面承認制とし、承認時は再委託先にも同等の義務を課すのが一般的である。
- 監査受入条項
- 委託元が委託先の実施状況を、立入りまたは書面によって確認できることを定めた契約条項。これがないと、問題を疑っても現地確認や証跡の提出を求める根拠がなく、報告書を信じるしかなくなる。
- 責任分界点
- クラウドなど外部サービスの利用で、事業者が守る範囲と利用者が守る範囲を分ける境目。SaaSでは基盤側は事業者、アカウント管理・アクセス権・公開設定・データ内容は利用者の責任となることが多い。
- 秘密保持義務(NDA)
- 業務で知った情報を外部に漏らさず、目的外に使わないことを約束する義務。委託契約の本体に条項として入れるか、別途の契約書として結ぶ。契約終了後も一定期間は義務が続くと定めるのが通例である。
- データの返却・削除
- 契約終了時に、預けた情報の原本と複製をすべて返してもらうか消してもらうこと。バックアップや作業用の複製が残りやすいため、範囲と期限を契約で定め、完了報告書などの証明を受け取るところまでを手順にする。
例題 委託先で個人データの漏えいが起きた。委託元として『委託先の責任なので当社は関係ない』と説明してよいか。
よくない。業務を委託しても情報を守る責任は委託元に残り、監督義務も委託元が負う。本人への連絡や公表、監督官庁への報告といった対外的な対応は委託元が主体となって判断し、委託先には事実の報告と是正を求める。
例題 委託先から『繁忙のため一部を協力会社に手伝わせたい』と電話で相談があった。どう答えるか。
契約の再委託条項に従い、電話での了承では済ませず、再委託先の名称・作業範囲・情報の取扱い方法を書面で提出させ、事前の書面承認の手続を踏む。承認する場合は、再委託先にも同等の秘密保持と安全管理を課すことを条件にする。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目B 委託先管理/科目A 情報セキュリティ管理・関連法規/JIS Q 27002(供給者関係)/個人情報保護法(委託先の監督)
人を育てる(教育と訓練)
規程は配っただけでは守られません。誰に何を伝え、どう訓練し、効果をどう測るかを、年間の計画として組み立てます。
情報セキュリティ教育の目的は、知識を増やすことではなく、業務のなかで正しく行動できるようにすることです。したがって『全員に同じ資料を配る』では足りず、相手の立場で内容を作り分けます。新入社員には業務を始める前に方針と基本ルールを、中途入社者には前職との違い(自社独自の申請手続や持出しのルール)を、一般社員には最新の手口と自社で起きた事例を、管理職には承認する立場としての責任と報告を受けたときのエスカレーションを、システム管理者には特権IDの扱いとログの確認を伝えます。派遣社員や委託先の従業者も、自社の情報に触れる以上は同じ水準の教育が必要で、雇用形態を理由に外してはいけません。
実施の時期は三つで考えると漏れません。入社時(業務を始める前)、年次(毎年決まった時期に全員へ)、変更時(規程を改訂したとき、新しいシステムを入れたとき、異動で扱う情報が変わったとき、社会的に大きな事故があったとき)です。特に変更時の教育は忘れられがちで、規程だけ改訂して周知しないと、現場は古いやり方のまま動き続けます。改訂した規程は、変更点を要約して配り、いつから適用されるかを明示します。
標的型攻撃メール訓練は、業務を装った訓練メールを送り、開封やリンクのクリック、そして報告の行動を確かめる訓練です。ここで最も誤解されやすいのが目的です。訓練は、開いてしまった人を特定して罰するためのものではありません。目的は、あやしいと感じたときにすぐ報告する行動を定着させること、報告窓口と連絡経路が実際に機能するかを確かめること、そして組織全体の弱いところを見つけて教育に反映することです。開封者の氏名を公表したり人事評価に用いたりすると、次からは開いたことを隠すようになり、本当の事故のときに報告が上がらなくなります。これは訓練が組織を弱くしてしまう典型例です。
訓練の指標も、開封率だけを見ないようにします。開封率は下がったが誰も報告していない状態より、開封率がやや高くても報告が短時間で多く上がる状態のほうが、実際の攻撃には強いといえます。報告率、初報までの時間、報告を受けてから注意喚起を出すまでの時間を測り、回を重ねて推移を見ます。結果は個人ではなく部門単位や全社の傾向として共有し、開封が多かった手口を次の教育の題材にします。
訓練には机上訓練と実動訓練もあります。机上訓練は、想定シナリオ(社内PCがランサムウェアに感染した、委託先から漏えいの連絡が入った、など)を配り、関係者が集まって『自分は次に何をするか』を順に確認する形式です。実際に手を動かさずに役割分担と判断の順序を確かめられるので、費用をかけずに始められます。インシデント対応訓練では、連絡先が古くなっていないか、休日に誰が受けるか、公表の判断は誰がするかといった、手順書の穴が見つかります。訓練の価値は、うまくできることではなく、できていないところを見つけることにあります。
実施の形式は、内容によって使い分けます。eラーニングは、全員に同じ内容を確実に届け、受講記録と理解度テストの点数が自動で残るため、年次教育や規程の周知に向きます。集合研修やグループ討議は、判断に迷う場面を扱うのに向き、自部門での具体例を出し合うことで自分ごとになります。短い注意喚起(メール配信や朝礼での一言)は、時事的な手口を素早く伝えるのに向きます。どれか一つに寄せず、組み合わせて年間計画に落とし込みます。
教育の記録は必ず保管します。誰がいつ何を受講したかの記録は、監査や委託元からの確認で証跡として求められますし、未受講者を追いかけるためにも必要です。そして効果測定です。受講率(100%に近づいているか)、理解度テストの正答率(どの設問で間違いが多いか)、訓練の報告率と初報までの時間、インシデントの件数と種類の推移を並べて見ると、教育のどこを直すべきかが見えてきます。これらは経営層への報告資料にもなります。経営層には、実施したという事実だけでなく、指標がどう動いたか、次に何を変えるかまでを短く報告し、必要な予算や全社への号令を得ることが、リーダーの重要な役割です。
教育・訓練の効果測定の例(数字の増減をどう読むか)
指標 前回 今回 見方 -------------------------------------- 受講率 82% 97% 未受講者の追跡が効いた 理解度テスト正答率 71% 78% 持出し手続の設問が低いまま 訓練メール開封率 18% 12% 改善だが単独では判断しない 訓練メール報告率 9% 31% 報告行動の定着が最大の成果 初報までの時間 94分 21分 窓口の周知が効いた ヒヤリハット報告件数 3件 17件 増加は悪化ではなく報告文化の改善
| 区分 | 対象・時期 | 主な内容とねらい |
|---|---|---|
| 対象別 | 新入社員 | 方針と基本ルール、報告の仕方。業務を始める前に線を示す |
| 対象別 | 中途入社者 | 前職との違い(申請手続、持出し、私物利用の可否)を明確にする |
| 対象別 | 一般社員 | 最新の手口と自社事例。誰が悪いかではなくどこで防げたかを扱う |
| 対象別 | 管理職 | 承認者としての責任、部下からの報告の受け方とエスカレーション |
| 対象別 | システム管理者 | 特権IDの扱い、ログの確認、変更手続の遵守 |
| 対象別 | 派遣・委託先従業者 | 自社の情報に触れる範囲での同等の教育と誓約。雇用形態で外さない |
| 時期別 | 入社時 | 業務開始前に実施。未実施のまま情報に触れさせない |
| 時期別 | 年次 | 全員に定期的に繰り返す。受講率と理解度で追跡する |
| 時期別 | 変更時 | 規程改訂・新システム導入・異動・大きな事故の発生時に随時実施 |
- 標的型攻撃メール訓練
- 業務を装った訓練メールを従業員に送り、開封や報告の行動を確かめる訓練。目的は開封者の処罰ではなく、報告行動の定着と報告経路の動作確認、弱点を教育へ反映することにある。指標は開封率だけでなく報告率も見る。
- 報告率
- 訓練メールを受け取った人のうち、窓口へ報告した人の割合。実際の攻撃では気づいた誰かの早い一報が被害を止めるため、開封率と並ぶ重要な指標とされる。初報までの時間と併せて見る。
- 机上訓練
- 想定シナリオを配り、関係者が集まって自分の行動と判断を口頭で確認する訓練。システムを実際に止めずに実施でき、役割分担の抜けや連絡先の古さなど手順書の穴を見つけやすい。
- 変更時教育
- 規程の改訂、新システムの導入、異動、大きな事故の発生など、前提が変わった時点で行う教育。入社時と年次だけでは現場が古い運用のまま残るため、変更点を要約して適用日とともに周知する。
- 効果測定
- 教育や訓練が行動を変えたかを指標で確かめること。受講率、理解度テストの正答率、訓練の報告率と初報までの時間、インシデント件数と種類の推移などを継続的に比べ、次の計画へ反映する。
- 教育記録
- 誰がいつどの教育を受け、理解度テストの結果がどうだったかを残した記録。未受講者の追跡に使うほか、内部監査や委託元からの確認の際に実施を裏づける証跡となるため、保管期間を決めて管理する。
例題 標的型攻撃メール訓練で、ある部門の開封率が突出して高かった。部門長から『開いた者の氏名を出してほしい、指導する』と言われた。どう答えるか。
氏名の提供と個人の指導は行わず、部門単位の傾向として結果を共有し、その部門で開封が多かった手口を題材に追加の教育を行うと説明する。処罰に使うと次回から開封を隠すようになり、実際の攻撃で報告が上がらなくなるため、訓練の目的である報告行動の定着に反する。
例題 年次教育の受講率が97%まで上がったのに、私物USBメモリでの持出しが後を絶たない。次に何を見るか。
受講率ではなく理解度テストの設問別の正答率と、現場の手続の使いやすさを見る。持出し手続の設問だけ正答率が低いなら教材の説明が不十分であり、正答率が高いのに守られないなら正規の申請が手間で回避されている可能性が高く、手続そのものの見直しを検討する。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目B 情報セキュリティ教育・訓練/科目A 情報セキュリティ対策(啓発活動)/JIS Q 27002(人的資源のセキュリティ・意識向上)
監査と改善につなげる
監査は粗探しではなく、決めたことが守られているかを確かめて次の一手を決める仕組みです。受ける側の作法と、指摘を改善へ回す流れを押さえます。
内部監査は、自社で決めた規程や基準のとおりに業務が行われているかを、業務の当事者ではない立場から確かめる活動です。準備の段階では、監査計画(いつ、どの部署を、誰が、どのくらいの時間で)、監査の対象範囲(どの業務・どの情報資産・どの期間を見るか)、監査基準(何と照らして良し悪しを判断するか。自社規程、ISMSの要求事項、契約条項、法令など)を先に決めます。基準を決めずに始めると、監査人の感想が指摘になってしまい、被監査部門は納得できません。
監査人には独立性が必要です。自分が担当している業務や自分の所属部署を自分で監査すると、都合の悪い事実を見逃したり、逆に説明を求められても客観的に判断できなくなります。そのため、監査対象部門に所属しない人が担当する、あるいは他部門の担当者と交代で監査し合う、外部の専門家に依頼するといった形をとります。情報システム部門が自ら構築した仕組みを情報システム部門の担当者が監査するのも、独立性の観点から避けるべき組み合わせです。
監査は事実に基づいて行います。判断の根拠になるものを監査証拠と呼び、規程や手順書、申請書と承認記録、アクセス権の一覧、教育の受講記録、ログ、入退室記録、担当者への質問の回答、実際の操作の観察などが該当します。特に、いつ誰が何をしたかを後から追える記録を監査証跡といい、これが残っていない業務は『やっているはずだが確かめられない』状態になります。口頭の説明だけでは証拠として弱いため、監査では必ず裏づけとなる記録を確認します。
被監査部門としての受け方にも作法があります。第一に事実を隠さないこと。都合の悪い運用を隠しても、証跡との突合せで見つかりますし、見つからなかった場合はリスクが放置されるだけで、得をする人は誰もいません。第二に、求められた証拠を用意しておくこと。事前に対象範囲が知らされるので、該当する申請書や記録をそろえ、担当者が説明できるようにしておきます。第三に、指摘を受けたら原因まで掘って是正計画を出すこと。担当者への注意で済ませると、同じ指摘が翌年も出ます。
指摘事項への対応は、是正・予防・フォローアップの三段階で考えます。是正は、見つかった不備そのものを直すこと(例:不要なアクセス権をいま削除する)。予防(再発防止)は、同じことが起きない仕組みに変えること(例:異動時に旧権限を削除する手順を組み込み、四半期ごとに棚卸しする)。フォローアップは、約束した期限に本当に実施されたかを監査側が確かめることです。是正だけで終わると再発し、計画を出しただけでフォローしないと実施されません。
監査の結果は経営層に報告され、マネジメントレビューで扱われます。マネジメントレビューは、監査結果、インシデントの発生状況、目標の達成度、外部環境の変化などを経営層が見て、方針や資源配分の見直しを決める場です。ここで決まったことが次の計画に反映され、計画(Plan)・実施(Do)・点検(Check)・見直し(Act)というPDCAが一周します。監査は点検にあたり、それ単独では価値が完結しないことを理解しておきます。
外部監査やISMSの審査を受けるときも、基本は同じです。ふだんの運用の記録がそのまま証拠になるので、審査のために書類を作り直すのではなく、日々の記録を残す運用にしておくことが最良の準備です。審査では、規程に自分たちで書いた内容が守られているかが見られるため、実行できない理想的な規程を書くと不適合の原因になります。報告書を読むときは、指摘のランク(重大な不適合、軽微な不適合、改善の機会や観察事項)と、いつまでに何をすべきかを区別して読み、期限のあるものから着手します。
改善が進まないときは、現場の努力不足として抱え込まず、上申します。是正に予算や人員、他部門の協力が要る場合、担当者や一部門の裁量では動かせません。そのときは、放置した場合に想定される影響(業務停止の可能性、法令違反、顧客への影響)と、必要な資源、対応しない場合のリスクの受容を誰が決めるのかを整理して経営層に上げます。リスクを受け入れるという判断も、責任を持てる立場の人が明示的に行うべきものであり、担当者が黙って先送りするのとはまったく違います。
内部監査の指摘一覧の例(区分と期限で優先度を判断する)
No 指摘事項 区分 期限 是正の状況 -------------------------------------------------------------------------- 1 退職者のアカウントが3件残存 不適合 9/30 済(削除完了) 2 異動時の旧権限の削除手順が未整備 不適合 10/31 未(計画提出のみ) 3 委託先の年次報告書が未読のまま保管 不適合 10/15 未(担当未定) 4 教育記録の保管期間が規程に未記載 改善の機会 次回改訂時 未 5 会議室の書類の置きっぱなし 改善の機会 随時 済(注意喚起)
| 段階 | 主体 | やること |
|---|---|---|
| 計画 | 監査部門・責任者 | 監査計画、対象範囲、監査基準を決め、独立性のある監査人を選ぶ |
| 準備 | 被監査部門 | 対象範囲に該当する規程・記録・証跡をそろえ、説明できる担当を決める |
| 実施 | 監査人 | 証拠に基づいて確認する。口頭説明は記録との突合せで裏づける |
| 報告 | 監査人 | 指摘事項を区分(不適合・改善の機会)して報告し、期限の目安を示す |
| 是正・予防 | 被監査部門 | 不備そのものを直し、原因をたどって再発しない仕組みに変える |
| フォローアップ | 監査人 | 期限到来時に実施状況を確認する。未実施なら理由を確かめ再設定する |
| 経営層への報告 | 責任者 | マネジメントレビューで方針・資源配分を見直し、次の計画へ反映する |
- 監査基準
- 監査で良し悪しを判断するときに照らす基準。自社の規程や手順書、ISMSの要求事項、契約条項、法令などを指す。あらかじめ決めておかないと、監査人の主観が指摘になり被監査部門が納得できない。
- 監査人の独立性
- 監査人が監査対象から利害的に切り離されていること。自部署や自分が構築・運用している仕組みは監査できない。他部門の担当者との相互監査や外部の専門家への依頼で確保する。
- 監査証跡
- いつ誰が何をしたかを後から追跡できる記録。ログ、申請書と承認記録、入退室記録などが該当する。残っていないと、適切に運用していても確かめられず、指摘の対象になる。
- フォローアップ
- 指摘に対する是正処置が、約束した期限までに実際に行われたかを監査側が確かめる活動。これがないと是正計画が出されただけで実行されず、翌年も同じ指摘が繰り返される。
- マネジメントレビュー
- 監査結果、インシデントの状況、目標の達成度、外部環境の変化などを経営層が見直し、方針や資源配分を決める場。PDCAのActにあたり、ここでの決定が次の計画に反映される。
- 不適合と改善の機会
- 審査での指摘の区分。不適合は要求事項を満たしていない状態で是正が必須、改善の機会(観察事項)は現時点で違反ではないがより良くできる点を示す。優先度が異なるため区別して読む。
例題 内部監査の指摘に対し『担当者に口頭で注意した』と回答したところ、翌年も同じ指摘が出た。何が足りなかったか。
是正はしたが予防(再発防止)をしていない。個人への注意ではなく、原因をたどって手順や仕組みに組み込む必要がある。例えば権限削除漏れなら、異動処理の手順に権限削除を必須の手順として入れ、定期棚卸しで確認する形にする。
例題 情報システム部門が構築した権限管理の仕組みを、同部門の担当者が内部監査することになった。問題はあるか。
ある。自分たちが構築・運用しているものを自分たちで監査するのは監査人の独立性を欠く。他部門の担当者や監査部門、外部の専門家が担当し、情報システム部門は説明と証拠の提出を行う側に回るべきである。
出典:IPA「情報セキュリティマネジメント試験(レベル2)」シラバス Ver.4.1 科目B 委託先管理・情報セキュリティ教育/科目A 情報セキュリティ管理(ISMS・監査)/マネジメント システム監査/JIS Q 27001(内部監査・マネジメントレビュー・改善)