セキュリティ対策を検討するとき、「最新の製品を入れるべきか」「運用を見直すべきか」という二択で考えてしまうことがあります。私は、この二つを分けて考えるべきではないと思っています。
使える製品は、早く導入したほうがいい。攻撃は、会社の準備が整うまで待ってくれません。個人情報の流出やクレジットカードの不正利用が起きている今、何も入れずに様子を見る理由はありません。
ただし、製品を契約した日が、対策の完了日になるわけではありません。製品から届く通知を誰が見るのか。緊急度を誰が決めるのか。対応した結果をどこに残すのか。ここまで決めて初めて、製品は会社を守る力になります。
使える道具は、先に入れる
守る側の道具は、以前より大きく進歩しています。クラウドの設定を確認する製品、端末の異常を見つける製品、プログラムの弱点を調べる製品、攻撃を再現して確かめる製品。選択肢はすでに十分あります。
AWSにも、AWS Security Agentがあります。設計書やソースコードなどからシステムの文脈を理解し、アプリケーションに対して多段階の攻撃を行い、実際に悪用できる可能性を検証して報告するサービスです。AWSは、ペネトレーションテストの所要期間を数週間から数日に短縮できると説明しています。
AWS以外にも、Google CloudのSecurity Command Center、MicrosoftのDefender for Cloud、CrowdStrikeのFalcon、Palo Alto NetworksのCortex、Snykなどがあります。大切なのは、AWSの製品だけを選ぶことではありません。自社の環境と課題に合う道具を選び、必要なものから導入することです。
導入を迷っている間にも、攻撃を受ける可能性は残ります。製品の比較に時間をかけすぎるより、まず使える道具を入れ、使いながら自社に合う形へ整えていくほうが現実的な場合もあります。
製品を入れた日が、始まりになる
セキュリティ製品を入れると、通知やアラートが届き始めます。ここで初めて、体制の問題が表に出ます。通知は届くが、誰も見ていない。見ているが、緊急度を判断できない。判断はできるが、対応する担当者が決まっていない。
この状態では、高価な製品を入れても効果が続きません。製品が悪いのではなく、製品を日々の仕事に組み込めていないからです。
体制をつくるために、最低限、次のことを決める必要があります。アラートを見る人、判断する責任者、実際に手を動かす担当者、対応結果を記録する場所。この四つが決まっていないと、通知は届いても行動につながりません。
体制づくりが、いちばん難しい
製品は契約できます。しかし、体制は購入できません。人が足りない、担当者が兼務している、夜間の連絡方法がない、判断の基準が人によって違う。こうした問題は、製品の機能を増やしても解決しません。
特に難しいのは、平常時ではなく異常時の役割を決めることです。誰が最初に通知を確認するのか。どの状態ならサービスを止めるのか。顧客や経営者への報告は誰が行うのか。外部の専門家へ相談する基準は何か。
これらは、会社の業務や責任分担によって答えが変わります。正解の製品を選ぶだけでは決まりません。自社の仕事を理解し、実際に動ける人と一緒に、何度も見直してつくる必要があります。だから体制づくりは、製品導入よりも難しく、時間がかかります。
運用は、平常時にこそ整える
事故が起きてから体制を考えると、判断が遅れます。平常時に、通知を確認する練習、連絡先の確認、対応手順の見直し、記録の確認を行っておく必要があります。
これは大きな訓練を毎月行うという意味ではありません。小さなアラートを題材に、誰が見て、誰に連絡し、どこまで対応したかを確認するだけでも、手順の問題は見えてきます。担当者が変わったときに同じように動けるかも重要です。
運用が整っている会社は、問題が起きない会社ではありません。問題が起きたときに、早く気づき、迷わず動き、後から説明できる会社です。
変更を安全に入れ続ける
セキュリティは、攻撃を見つけるだけではありません。システムを安全に変更し続けることも含まれます。設定を変える、ソフトウェアを更新する、新しい機能をリリースする。変更のたびに、別の問題が起きる可能性があります。
GoogleのSREチームは、障害のおよそ70%が稼働中のシステムへの変更に起因するとしています。変更を止めれば事故は減りますが、古いソフトウェアや未対応の脆弱性が残ります。必要なのは、変更をやめることではなく、小さく変更し、確認し、問題があれば戻せる状態です。
そのためには、テスト、検知、試験、リリースの順番を決めます。変更前に確認し、変更後に異常へ気づき、戻し方を試し、影響を小さくしたうえで提供する。夜中に一度だけ大きな変更を行うより、日中に小さく安全に変更できる仕組みのほうが、長い目で見て安定します。
これから守る対象が広がる
いま起きている個人情報の流出やクレジットカードの不正利用は、深刻な問題です。一方で、これから起きることの序章にすぎないとも考えています。
ネットワークにつながるものは、すべて攻撃の対象になり得ます。IoTデバイス、監視カメラ、病院の設備、冷蔵庫、携帯電話、車、電車、飛行機。これらは単なる情報システムではなく、人の生活や社会の機能を支える設備です。
脅かしたいわけではありません。ただ、これから起きる可能性のある現実から目を背けることはできません。対象が広がれば、確認する情報も、対応する場所も増えます。人だけで全てを見続けることは難しくなります。
守るために、AIを使う
攻撃側がAIを使って速く、安く、巧妙に動くなら、守る側もAIを使わなければ追いつけません。大量のログを整理し、異常の候補を見つけ、過去の事例と照らし合わせ、対応の優先順位を提案する。AIは、これからのセキュリティに必須の道具になります。
ただし、AIに全てを任せればよいという意味ではありません。AIが出した結果を人が確認し、重要な判断には承認を置き、実行した操作を記録する。AIを使うためにも、体制とルールが必要です。
AIは脅威を大きくした原因でもあり、守る側の力にもなります。どちらになるかは、導入するかどうかだけでなく、どう運用するかで決まります。
お客さまと体制をつくる
RHEMS Japanは、セキュリティ製品を紹介して終わるのではなく、お客さまが継続して使える体制を一緒につくりたいと考えています。製品の選定、導入、通知の整理、判断基準の作成、対応手順、記録の残し方まで、実際の業務に合わせて考えます。
道具の導入は、数週間で終わるかもしれません。体制づくりは、運用しながら改善していく仕事です。担当者が変わっても続けられるか、夜間に問題が起きても連絡できるか、経営者やお客さまへ説明できるか。そこまで含めて、安定したシステムを維持することが私たちの役割です。
使える道具は早く入れる。そして、その道具を使い続けられる体制をつくる。この二つを同時に進めることが、現実的なセキュリティ対策だと考えています。
関連する記事: 障害の7割は変更から来る — 戻せる形・検知できる形を作る
現在の運用や課題を伺い、必要な道具と体制の優先順位から一緒に考えます。お問い合わせください。
参考
- Google「Site Reliability Engineering」第1章 — 障害のおよそ70%は、稼働中のシステムへの変更に起因するという経験則
- IPA「情報セキュリティ10大脅威 2026」 — AIの利用をめぐるサイバーリスク、個人情報の窃取、クレジットカード情報の不正利用
- AWS「AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始」 — 2026年3月31日の一般提供開始と、自律型テストの位置づけ
- AWS「AWS Security Agent の特徴」 — 設計書・コードからの文脈理解と検証済みの脆弱性の報告
- 国連条約集「UN Regulation No. 155（自動車のサイバーセキュリティ）」 — 自動車のサイバーセキュリティ規制
2026年11月時点の公開情報と、当社の運用の経験に基づく見解です。製品の効果や費用は提供元の説明によります。