講義資料　セキュリティ認証の落とし穴

認証を受けていても、人的ミス・運用ミスは起きる

1. はじめに

情報セキュリティ認証や個人情報保護に関する認証を取得している企業・団体であっても、情報漏えい、不正アクセス、ランサムウェア被害、誤設定による公開事故は発生します。

ここで重要なのは、
「認証を取っているのに事故が起きたから認証は意味がない」
という話ではありません。

本当に重要なのは、
認証取得後も、現場でルールが継続的に運用されているか
人がミスをしにくい仕組みになっているか
委託先・クラウド・権限・ログ・パッチ管理まで確認できているか
という点です。

2. 認証はゴールではなく、スタートライン

セキュリティ認証は、一定の管理体制やルールが整備されていることを確認するものです。

しかし、認証を取得しただけで、次のような問題が自動的に解決されるわけではありません。

• 現場担当者の確認不足
• 管理者アカウントの使い回し
• 退職者アカウントの放置
• 委託先作業の実態把握不足
• クラウドサービスの設定ミス
• ソフトウェア更新の遅れ
• ログを取得しているだけで確認していない状態
• 年1回の研修だけで現場行動が変わっていない状態

つまり、認証は「安全を保証する盾」ではなく、
安全を維持するための仕組みを継続的に回すための土台です。

3. 匿名化事例：認証を受けていても事故は起きる

ケースA：業務システム提供会社のランサムウェア被害

ある業務システム提供会社では、重要な個人情報を扱うクラウド型サービスがランサムウェア被害を受け、利用者側の業務にも大きな影響が出ました。

公表情報では、以下のような問題が指摘されました。

• 管理者パスワードの管理が不十分だった
• 推測されやすいパスワードが使われていた
• セキュリティ更新が遅れていた
• ログ監視が十分ではなかった
• 外部からの侵入に対する検知・対応が遅れた

この会社は、個人情報保護に関する認証を取得していました。

講義でのポイント

認証を取得していても、
特権ID管理、パスワード管理、脆弱性対応、ログ監視が崩れると重大事故になる
という事例です。

ケースB：大量の個人情報を扱う委託事業者の事故

ある委託事業者では、ランサムウェア被害により、大量の個人情報が漏えいした可能性が公表されました。

その後、同社が取得していたセキュリティ関連認証や個人情報保護認証について、一時停止や是正対応が行われました。

講義でのポイント

認証は取得して終わりではありません。

重大事故が発生した場合、
認証の一時停止、再審査、是正措置、再発防止策の提出
が求められることがあります。

つまり、認証は看板ではなく、
継続的に説明責任を果たすための仕組みです。

ケースC：写真共有・写真販売サービスの不正アクセス

ある写真共有・写真販売サービスで不正アクセスが発生し、利用者の氏名、住所、メールアドレス、パスワード等が漏えいした可能性が公表されました。

この種のサービスでは、学校、園、イベント、保護者、子どもに関する情報を扱うことが多く、漏えい時の影響は金銭被害だけにとどまりません。

講義でのポイント

写真共有系サービスでは、
「写真そのもの」だけでなく、氏名、所属、イベント名、学校名、家族関係などが組み合わさること
がリスクになります。

認証を取得していても、
脆弱性管理、アクセス制御、パスワード管理、外部公開設定の確認
を継続できていなければ事故は起こります。

ケースD：学校・保育・教育関連写真サービスの情報漏えい

ある教育・保育関連の写真サービスで、購入者情報や団体情報などが漏えいした可能性が公表されました。

対象には、保護者、学校、園、イベント参加者などが含まれる可能性がありました。

講義でのポイント

教育・保育・学校関連の情報は、一般企業の顧客情報以上に慎重な扱いが求められます。

理由は、
本人だけでなく、子ども、保護者、学校、地域、行事情報が紐づく可能性がある
からです。

認証があるかどうかだけではなく、
サービスの設計、権限管理、閲覧範囲、事故時の通知体制
まで確認する必要があります。

ケースE：大学のクラウドサービス設定ミス

ある大学では、クラウド型のID管理サービスや情報共有サービスの設定不備により、教職員や学生の情報が、本来見えるべきではない範囲に表示される状態になっていました。

原因としては、以下のようなものが考えられます。

• クラウドサービスの仕様理解不足
• 初期設定の確認不足
• 追加機能や仕様変更への対応不足
• 権限設定の点検不足
• 導入後の定期確認不足

講義でのポイント

クラウドサービスは便利ですが、
導入した瞬間よりも、運用開始後の設定確認が重要
です。

特に大学や学校では、学生、教職員、非常勤講師、委託先など、多くの利用者が関わります。

そのため、
誰が、何を、どこまで見られるのか
を定期的に確認しなければなりません。

ケースF：大学の委託先管理不足

ある大学では、委託先が本来のルールと異なる形でデータを持ち出し、委託先環境でランサムウェア被害を受けたことで、個人情報漏えいの可能性が発生しました。

問題は、大学側にルールがなかったことだけではありません。

重要なのは、
委託先が実際にルール通り作業していたかを確認できていたか
という点です。

講義でのポイント

契約書に書いてあるだけでは不十分です。

委託先管理では、以下を確認する必要があります。

• データの持ち出しルール
• 作業場所
• 保存先
• アクセス権限
• 再委託の有無
• 作業完了後のデータ削除
• 事故発生時の報告ルート
• 定期的な運用確認

委託先事故は、委託先だけの問題ではありません。
発注側にも、安全管理措置と監督責任 が問われます。

4. 認証取得企業でも起こりやすい人的ミス

認証を取得している企業・団体でも、以下のような人的ミスは起こります。

5. 重要なのは「認証の有無」ではなく「継続できているか」

セキュリティ認証を取得しているかどうかは、取引先を選ぶうえで重要な判断材料になります。

しかし、それだけでは不十分です。

確認すべきなのは、次の点です。

• 認証取得後も教育を継続しているか
• ルールが現場で実行可能な内容になっているか
• 内部監査が形式的になっていないか
• 委託先の作業実態を確認しているか
• クラウド設定を定期的に見直しているか
• 管理者権限を最小化しているか
• 退職者・異動者のアカウントを削除しているか
• ログを取得するだけでなく確認しているか
• 事故発生時の連絡・報告ルートが明確か

6. 本質

人的ミスは、単に「人が悪い」だけではありません。

実際には、次のような状態がミスを誘発します。

• 手順が複雑すぎる
• チェックする人が決まっていない
• 忙しい現場で確認作業が省略される
• 例外運用が常態化している
• システムの画面が分かりにくい
• 権限設定が複雑で理解されていない
• 研修が一度きりで終わっている
• 責任範囲が曖昧になっている

つまり、人的ミス対策とは、
人を責めることではなく、人がミスをしにくい仕組みに変えること
です。

7. まとめ

セキュリティ認証は重要です。

しかし、認証は万能ではありません。

認証を取得していても、
パスワード管理、権限管理、委託先管理、クラウド設定、ログ監視、教育、内部監査
が継続できていなければ、事故は起こります。

大切なのは、
「認証を取っているか」ではなく、
「認証で決めたルールが、今も現場で機能しているか」
です。

セキュリティは、取得するものではなく、
毎日運用し続けるものです。

認証を受けていても、人的ミス・運用ミスは起きる

1. はじめに

情報セキュリティ認証や個人情報保護に関する認証を取得している企業・団体であっても、情報漏えい、不正アクセス、ランサムウェア被害、誤設定による公開事故は発生します。

ここで重要なのは、
「認証を取っているのに事故が起きたから認証は意味がない」
という話ではありません。

本当に重要なのは、
認証取得後も、現場でルールが継続的に運用されているか
人がミスをしにくい仕組みになっているか
委託先・クラウド・権限・ログ・パッチ管理まで確認できているか
という点です。

2. 認証はゴールではなく、スタートライン

セキュリティ認証は、一定の管理体制やルールが整備されていることを確認するものです。

しかし、認証を取得しただけで、次のような問題が自動的に解決されるわけではありません。

• 現場担当者の確認不足
• 管理者アカウントの使い回し
• 退職者アカウントの放置
• 委託先作業の実態把握不足
• クラウドサービスの設定ミス
• ソフトウェア更新の遅れ
• ログを取得しているだけで確認していない状態
• 年1回の研修だけで現場行動が変わっていない状態

つまり、認証は「安全を保証する盾」ではなく、
安全を維持するための仕組みを継続的に回すための土台です。

3. 匿名化事例：認証を受けていても事故は起きる

ケースA：業務システム提供会社のランサムウェア被害

ある業務システム提供会社では、重要な個人情報を扱うクラウド型サービスがランサムウェア被害を受け、利用者側の業務にも大きな影響が出ました。

公表情報では、以下のような問題が指摘されました。

• 管理者パスワードの管理が不十分だった
• 推測されやすいパスワードが使われていた
• セキュリティ更新が遅れていた
• ログ監視が十分ではなかった
• 外部からの侵入に対する検知・対応が遅れた

この会社は、個人情報保護に関する認証を取得していました。

講義でのポイント

認証を取得していても、
特権ID管理、パスワード管理、脆弱性対応、ログ監視が崩れると重大事故になる
という事例です。

ケースB：大量の個人情報を扱う委託事業者の事故

ある委託事業者では、ランサムウェア被害により、大量の個人情報が漏えいした可能性が公表されました。

その後、同社が取得していたセキュリティ関連認証や個人情報保護認証について、一時停止や是正対応が行われました。

講義でのポイント

認証は取得して終わりではありません。

重大事故が発生した場合、
認証の一時停止、再審査、是正措置、再発防止策の提出
が求められることがあります。

つまり、認証は看板ではなく、
継続的に説明責任を果たすための仕組みです。

ケースC：写真共有・写真販売サービスの不正アクセス

ある写真共有・写真販売サービスで不正アクセスが発生し、利用者の氏名、住所、メールアドレス、パスワード等が漏えいした可能性が公表されました。

この種のサービスでは、学校、園、イベント、保護者、子どもに関する情報を扱うことが多く、漏えい時の影響は金銭被害だけにとどまりません。

講義でのポイント

写真共有系サービスでは、
「写真そのもの」だけでなく、氏名、所属、イベント名、学校名、家族関係などが組み合わさること
がリスクになります。

認証を取得していても、
脆弱性管理、アクセス制御、パスワード管理、外部公開設定の確認
を継続できていなければ事故は起こります。

ケースD：学校・保育・教育関連写真サービスの情報漏えい

ある教育・保育関連の写真サービスで、購入者情報や団体情報などが漏えいした可能性が公表されました。

対象には、保護者、学校、園、イベント参加者などが含まれる可能性がありました。

講義でのポイント

教育・保育・学校関連の情報は、一般企業の顧客情報以上に慎重な扱いが求められます。

理由は、
本人だけでなく、子ども、保護者、学校、地域、行事情報が紐づく可能性がある
からです。

認証があるかどうかだけではなく、
サービスの設計、権限管理、閲覧範囲、事故時の通知体制
まで確認する必要があります。

ケースE：大学のクラウドサービス設定ミス

ある大学では、クラウド型のID管理サービスや情報共有サービスの設定不備により、教職員や学生の情報が、本来見えるべきではない範囲に表示される状態になっていました。

原因としては、以下のようなものが考えられます。

• クラウドサービスの仕様理解不足
• 初期設定の確認不足
• 追加機能や仕様変更への対応不足
• 権限設定の点検不足
• 導入後の定期確認不足

講義でのポイント

クラウドサービスは便利ですが、
導入した瞬間よりも、運用開始後の設定確認が重要
です。

特に大学や学校では、学生、教職員、非常勤講師、委託先など、多くの利用者が関わります。

そのため、
誰が、何を、どこまで見られるのか
を定期的に確認しなければなりません。

ケースF：大学の委託先管理不足

ある大学では、委託先が本来のルールと異なる形でデータを持ち出し、委託先環境でランサムウェア被害を受けたことで、個人情報漏えいの可能性が発生しました。

問題は、大学側にルールがなかったことだけではありません。

重要なのは、
委託先が実際にルール通り作業していたかを確認できていたか
という点です。

講義でのポイント

契約書に書いてあるだけでは不十分です。

委託先管理では、以下を確認する必要があります。

• データの持ち出しルール
• 作業場所
• 保存先
• アクセス権限
• 再委託の有無
• 作業完了後のデータ削除
• 事故発生時の報告ルート
• 定期的な運用確認

委託先事故は、委託先だけの問題ではありません。
発注側にも、安全管理措置と監督責任 が問われます。

4. 認証取得企業でも起こりやすい人的ミス

認証を取得している企業・団体でも、以下のような人的ミスは起こります。

5. 重要なのは「認証の有無」ではなく「継続できているか」

セキュリティ認証を取得しているかどうかは、取引先を選ぶうえで重要な判断材料になります。

しかし、それだけでは不十分です。

確認すべきなのは、次の点です。

• 認証取得後も教育を継続しているか
• ルールが現場で実行可能な内容になっているか
• 内部監査が形式的になっていないか
• 委託先の作業実態を確認しているか
• クラウド設定を定期的に見直しているか
• 管理者権限を最小化しているか
• 退職者・異動者のアカウントを削除しているか
• ログを取得するだけでなく確認しているか
• 事故発生時の連絡・報告ルートが明確か

6. 講義で伝えるべき本質

人的ミスは、単に「人が悪い」だけではありません。

実際には、次のような状態がミスを誘発します。

• 手順が複雑すぎる
• チェックする人が決まっていない
• 忙しい現場で確認作業が省略される
• 例外運用が常態化している
• システムの画面が分かりにくい
• 権限設定が複雑で理解されていない
• 研修が一度きりで終わっている
• 責任範囲が曖昧になっている

つまり、人的ミス対策とは、
人を責めることではなく、人がミスをしにくい仕組みに変えること
です。

7. まとめ

セキュリティ認証は重要です。

しかし、認証は万能ではありません。

認証を取得していても、
パスワード管理、権限管理、委託先管理、クラウド設定、ログ監視、教育、内部監査
が継続できていなければ、事故は起こります。

大切なのは、
「認証を取っているか」ではなく、
「認証で決めたルールが、今も現場で機能しているか」
です。

セキュリティは、取得するものではなく、
毎日運用し続けるものです。

8. 業者選定時に、当社が間に入る場合の確認質問例

セキュリティ認証を取得している業者であっても、発注側は「認証がありますか？」だけで判断してはいけません。

当社が業者選定やIT導入支援の間に入る場合は、認証の有無だけではなく、
その認証が現在も有効に運用されているか
現場レベルで事故を防ぐ仕組みがあるか
を確認します。

以下は、選定業者に投げる質問文の一例です。

① 認証・管理体制に関する質問

貴社が取得している情報セキュリティ関連認証、個人情報保護関連認証があれば教えてください。

その認証の対象範囲は、今回当社が利用を検討しているサービス・業務に含まれていますか。

認証の有効期限、直近の更新審査日、次回審査予定日を教えてください。

直近の審査や内部監査で、重大な指摘事項はありましたか。

指摘事項があった場合、どのような是正措置を実施しましたか。

情報セキュリティ責任者、個人情報保護管理者、事故対応責任者は明確に定められていますか。

② 個人情報・機密情報の取り扱いに関する質問

当社から預かる情報は、どの範囲の担当者が閲覧できますか。

担当者ごとにアクセス権限は分離されていますか。

管理者権限を持つ担当者は何名程度いますか。

管理者権限の付与・変更・削除の承認手続きはありますか。

退職者や異動者のアカウント削除は、どのタイミングで実施されますか。

当社データをローカルPC、USBメモリ、個人端末、私用クラウドに保存することは禁止されていますか。

データをダウンロードできる担当者は制限されていますか。

業務終了後、当社データはどのように削除・返却されますか。

③ 委託先・再委託に関する質問

今回の業務で再委託は発生しますか。

再委託がある場合、再委託先の会社名、業務範囲、取り扱う情報の種類を教えてください。

再委託先にも、貴社と同等のセキュリティ基準を求めていますか。

再委託先の作業実態をどのように確認していますか。

再委託先で事故が発生した場合、当社への報告ルートと報告期限を教えてください。

再委託先のさらに先への再々委託は禁止されていますか。

④ クラウドサービス・システム設定に関する質問

利用しているクラウドサービス名、データ保存国、管理者権限の管理方法を教えてください。

クラウドサービスの共有設定や公開設定は、定期的に点検していますか。

新機能追加や仕様変更があった場合、権限設定への影響を確認していますか。

外部公開リンクを発行できる場合、発行権限は制限されていますか。

ファイル共有時に、閲覧期限、ダウンロード制限、パスワード、二要素認証などを設定できますか。

誤って外部公開された場合、検知・停止・報告する手順はありますか。

⑤ アカウント・パスワード・認証に関する質問

管理者アカウントに二要素認証は必須化されていますか。

一般利用者にも二要素認証を設定できますか。

パスワードポリシーはどのように定めていますか。

共有IDの利用は禁止されていますか。

初期パスワードのまま利用されない仕組みはありますか。

ログイン失敗回数によるロック、異常ログイン検知、海外IP制限などはありますか。

特権IDの操作ログは記録されていますか。

⑥ 脆弱性管理・更新管理に関する質問

OS、ミドルウェア、CMS、プラグイン、ライブラリ等の更新管理はどのように行っていますか。

重大な脆弱性が公表された場合、何日以内に影響確認を行いますか。

緊急パッチ適用の判断基準はありますか。

定期的な脆弱性診断や外部診断は実施していますか。

診断結果で重大・高リスクの指摘があった場合、是正期限を設けていますか。

使用していない古いシステム、古いアカウント、古いプラグインを棚卸ししていますか。

⑦ ログ監視・不正アクセス対策に関する質問

ログイン履歴、管理者操作履歴、データダウンロード履歴は記録されていますか。

ログはどのくらいの期間保存していますか。

ログは取得するだけでなく、定期的に確認していますか。

異常なアクセスや大量ダウンロードを検知する仕組みはありますか。

不審なアクセスが確認された場合、誰が、どのように判断し、どのタイミングで当社へ報告しますか。

事故発生時に、原因調査に必要なログを提出できますか。

⑧ バックアップ・ランサムウェア対策に関する質問

バックアップはどの頻度で取得していますか。

バックアップデータは本番環境と分離されていますか。

バックアップからの復旧テストは実施していますか。

ランサムウェア感染時に、どの時点まで復旧可能ですか。

復旧にかかる想定時間を教えてください。

バックアップも同時に暗号化・破壊されない設計になっていますか。

⑨ 事故発生時の報告体制に関する質問

情報漏えい、不正アクセス、誤送信、誤公開が発生した場合、当社へ何時間以内に第一報を行いますか。

第一報には、どのような情報が含まれますか。

事故発生時の連絡窓口は、平日・夜間・休日で分かれていますか。

個人情報保護委員会、監督官庁、利用者への報告が必要になった場合、役割分担はどうなりますか。

原因調査、再発防止策、報告書提出までの標準的な流れを教えてください。

過去に重大な情報セキュリティ事故を公表したことはありますか。

事故があった場合、その後どのような再発防止策を実施しましたか。

⑩ 教育・人的ミス対策に関する質問

従業員向けのセキュリティ教育は年何回実施していますか。

新入社員、派遣社員、アルバイト、委託先担当者にも教育を実施していますか。

メール誤送信、添付ファイル誤送信、CC/BCCミスへの対策はありますか。

個人情報を扱う作業では、ダブルチェックや承認フローがありますか。

人的ミスが発生した場合、個人責任で終わらせず、手順や仕組みを見直す体制はありますか。

作業手順書は定期的に更新されていますか。

現場担当者がルールを理解しているか、確認する仕組みはありますか。

9. 当社が重視する判断基準

当社が業者選定で重視するのは、
認証を持っているかどうかだけではありません。

特に以下を重視します。

• 認証の対象範囲が、今回の業務に含まれているか
• セキュリティ責任者と連絡体制が明確か
• 委託先・再委託先まで管理できているか
• クラウド設定や権限設定を定期的に確認しているか
• ログを取得するだけでなく、実際に確認しているか
• 脆弱性やパッチ対応の期限が決まっているか
• 事故発生時の第一報が早いか
• 過去の事故や指摘を隠さず、是正内容を説明できるか
• 現場担当者が守れる運用になっているか

10. 危険な回答例

以下のような回答が返ってきた場合は、注意が必要です。

11. まとめ

業者選定では、
「認証を持っていますか？」だけでは不十分です。

本当に確認すべきなのは、
認証で決めたルールが、現在も現場で運用されているか
委託先やクラウド設定まで管理できているか
事故が起きたときに、早く、正確に、誠実に報告できるか
です。

認証は選定条件の一つです。

しかし、最終的に重要なのは、
認証マークではなく、運用実態です。