企業がクラウドサービスを選ぶとき、「ISMS認証やプライバシーマーク（Pマーク）を取得していますか」と確認することがあります。第三者の評価を選定材料にするのは当然のことです。しかし、 認証マークがあることと、情報漏洩が絶対に起きないことは同じではありません。
社内ルール、責任分担、教育、継続的な改善の状況を第三者機関が認定する制度の価値に意味があります。一方、クラウドサービスを利用する立場なら、もう一歩踏み込んで、日々のシステム更新や認証の仕組みを確かめる必要があると考えています。
大切なのは、昨日の審査結果より、今日の脆弱性にどう対応するかです。これは、私たちがセキュリティ運用で重視する姿勢を端的に表す言葉です。
情報漏洩の報道では、「不正アクセスを受けた」「ランサムウェアによる被害が発生した」と説明される一方、具体的な侵入経路や防げた可能性までは広く伝わらないことがあります。原因が未確定の場合や二次被害防止のために詳細を公開できない場合もあり、報道に詳細がないために、漏洩の直接理由まで外部からはわからないケースが多いです。
そのため、原因が分からない限り、利用者は適切な対策を判断できません。「クラウドだから危険」「聞いたことのない小さな会社だから不安」といった漠然とした印象だけでは、安全性を評価しにくいのも事実です。
クラウドサービスの選定で問いたいのは、企業規模や認証取得の有無に加えて、具体的に何を守り、どのように更新し、問題が起きたときにどう対応するのかという点です。
ISMS（ISO/IEC 27001）は、情報セキュリティ上のリスクを把握し、組織として管理策を選択・運用し、改善するためのマネジメントシステムです。プライバシーマークは、個人情報保護の体制やその運用を評価する制度です。
どちらも組織としての規律や継続的改善を後押しする仕組みです。また、ISMSの管理策には技術的脆弱性の管理なども含まれます。
制度の審査には対象となる組織・業務・システムの範囲があり、すべてのサーバ、設定、アプリケーションを常時検査して安全を保証するものではありません。認証取得後にも新たな脆弱性は発見されるからです。
認証マークは参考情報として確認しながら、対象範囲、実際の技術対策、最近の対応履歴を合わせて確かめることが大切です。
原因は様々です。たとえば、外部公開されたVPN装置やWebアプリケーションの脆弱性、漏洩した認証情報、アクセス制御の設定ミス、内部者の不正な持ち出しなど、複数の経路が考えられます。
重要な資料を紹介します。個人情報保護委員会の「令和7年度年次報告」では、不正アクセスによる漏洩等の原因として、VPN機器やECサイト用アプリケーションの脆弱性について対処方法が公開済みだったにもかかわらず、事業者が放置していたこと、推測されやすいID・パスワード、アクセス制御の設定ミスなど、安全管理措置の不備が多くみられたと説明しています。
これは、「漏洩の8割がアップデート忘れ」「パッチさえ当てれば9割防げる」という意味ではありません。そうした割合を一律に断定できる根拠はありません。しかし、既知の脆弱性への対処の遅れが、現実の事故で問題になっていることは公的資料から確認できます。
また「情報漏洩が判明した」場合でも、不正なデータ持ち出しをログで確認したケース、外部公開を確認したケース、漏洩の可能性を否定できないケースなど、確認できた事実の程度が異なります。報道を読む際は、何が確認済みで何が調査中かを区別したいものです。
OS、Webサーバ、データベース、ライブラリ、VPN装置などに脆弱性が見つかると、修正情報が公開されることがあります。攻撃者が公開済みの情報を利用して未対策のシステムを探します。だからこそ、管理者には自社が使う製品を把握し、影響を調べ、優先順位をつけて対応する運用が求められます。
IPAは製品の脆弱性に関する緊急対策情報や注意喚起を継続的に公開しています。IPAの脆弱性対策情報も、運用時に参照すべき公開情報の一つです。
更新には不具合や互換性の問題が伴うため、重大な脆弱性の検知と影響評価、修正方法の確認、テスト、適用、適用後の確認までが対策です。監視は自動化しながら、更新の実行判断を人が行う運用が合理的です。
定期的な更新対応だけでなく、緊急性が高いときにどう動くかが問われます。
セキュリティは、侵入されないための対策だけで完結しません。通信経路の暗号化、保存時の暗号化、アクセス権限の制限、バックアップ、記録の監視などを組み合わせることが重要です。
保存時の暗号化は、記憶装置やファイルを直接持ち出された際のリスク低減に役立ちます。一方、正規アプリケーションが復号した後の情報を攻撃者に読み取られた場合には、暗号化だけで情報の持ち出しを阻止できません。暗号鍵をどこに保管し、誰が復号できるかも含めて設計する必要があります。
さらに、そもそも必要以上の個人情報を預けないことも効果的です。氏名を使わず管理番号で業務を回す方法などは、別記事「クラウドに預ける情報を減らすQRコード管理」で詳しく紹介しています。
パスキーはFIDO2の公開鍵暗号方式を使い、サービス側にパスワードに相当する共通の秘密を預けずに認証します。偽サイトに入力したパスワードを盗まれるようなフィッシングへの耐性が高い方式です。
ただし、新しいパスキーの入口を追加しても、従来のID/パスワードからのログインもできる状態を残せば、その古い経路が攻撃対象になり得ます。導入して終わりではなく、弱い認証経路を残さない設計が重要です。
ハネソルのWebサービス「キューRクラウド」では、パスキーの登録時にメールによるワンタイムパスワード（OTP）確認を行い、パスキー登録後はその利用者のID/パスワードによるログインを自動的に無効化しています。
万が一、端末の紛失、故障などで認証手段を失った場合は、個別に問い合わせを受け、メールや電話によるコミュニケーションと本人しか知り得ない情報の確認を経て、担当者がロック解除を判断します。
大規模企業には専門人員や多層的な体制の強みがありますが、多数のシステム、担当部署、委託先を横断して更新状況を把握する難しさもあります。一方、小規模な会社では管理対象を把握しやすく、対応判断を速くできるメリットがあります。
ハネソルは、ISMS・Pマークの取得はしていません。認証取得のための社内体制や維持への経営資源を配分する前に、現サービスの技術的対策と実運用を優先する方針を採っています。認証制度の取得も大切ですが、小さな企業にとって限られた経営資源の使い方に関する私たちの判断です。
外部の月次診断だけですべての問題が見つかるわけではありません。バックアップがあっても情報漏洩そのものを防止するわけでもありません。対策の目的と限界を分けて、必要な改善を続けております。
ISMSやPマークを確認したら、次のような質問もしてみてください。どの事業者に対しても活用できる評価項目です。
すべての質問に「はい」と答えることよりも、対象範囲、例外、対応期限、責任者を具体的に説明できることが重要です。
ISMSやPマークには大切な役割があります。しかし、認証は安全対策を考えるための出発点であって、事故が起きないことの保証ではありません。
脆弱性を発見したら何をするのか。更新は滞っていないか。保存情報は必要最小限か。ログイン方法に弱い抜け道がないか。そして万が一の事故にどう向き合うのか。
大切なのは、昨日の審査結果より、今日の脆弱性にどう対応するか。
ハネソルは、認証制度の有無だけで企業の安全性を決めるのではなく、実際の設計と運用の中身を評価していただきたいと考えています。私たち自身も、対策の内容と限界をできるだけ具体的に説明しながら、改善を積み重ねていきます。
キューRクラウドのセキュリティ機能・運用については、「キューRクラウドのセキュリティページ」もご覧ください。
