端末・SOC
EDRとアンチウイルスの違い|併用・費用・運用の選び方
アンチウイルス(AV)はマルウェアの予防・検知・対処を担い、EDRは端末の挙動を使った検知・調査・対応を支える。機能は重なり、別製品を2本購入することが必須という意味ではない。端末の予防機能を維持したうえで、調査・隔離を担当できる体制と契約範囲で選ぶ。
判断に使う場面: 予防機能の未導入・更新停止があるなら、その解消と資産把握を優先する。EDR導入を待って既存保護を外さない。
比較
EDRとアンチウイルス、認証と認可、CVEとCVSS、SIEMとSOARなど、混同しやすいセキュリティ用語の違いを整理。
Find by decision context
30件の用語比較を表示中
端末・SOC
アンチウイルス(AV)はマルウェアの予防・検知・対処を担い、EDRは端末の挙動を使った検知・調査・対応を支える。機能は重なり、別製品を2本購入することが必須という意味ではない。端末の予防機能を維持したうえで、調査・隔離を担当できる体制と契約範囲で選ぶ。
判断に使う場面: 予防機能の未導入・更新停止があるなら、その解消と資産把握を優先する。EDR導入を待って既存保護を外さない。
認証・ID
認証は「誰か」を確認すること、認可は「何をしてよいか」を決めること。ログインできても、すべての操作が許可されるわけではない。
判断に使う場面: ログイン機能を作るときは認証と認可を別のテスト観点にする
脆弱性・リスク
CVEは脆弱性を共通の番号で識別し、CVSSは技術的な深刻度を評価する。番号があること、点数が高いこと、自社が影響を受けることは別の判断。公式の対象製品・版を照合し、CVSSの版・評価元・ベクター、悪用情報、公開範囲と業務影響をそろえて対応を決める。
判断に使う場面: 脆弱性の連絡を受けたら、CVEで情報を突き合わせ、製品名だけでなく版・機能・導入形態まで確認する。CVEの詳細公開や採点完了を緊急対応の待機条件にしない。
端末・SOC
SIEMはログの収集・検索・相関分析で検知と調査を支え、SOARは調査・通知・対応の手順を連携して実行する。役割の比較であり、別製品の購入を必須とする区分ではない。
判断に使う場面: 導入順序:ログ不足で原因を追えないなら、まず取得・検索・保存・担当を整える。既に調査の根拠が揃い反復作業が詰まるなら、通知・チケット・読み取り照会から自動化する。製品を入れる前に業務の不足を選ぶ。
端末・SOC
IDSは侵入の兆候の検知・通知を、IPSは検知に加え通信の阻止を担う。ここではネットワーク型を中心に、受動監視とインライン検査を比較する。可視化と調査が目的なら監視を、通信を止める必要があり誤遮断・性能・復旧条件を管理できるならIPSの遮断運用を検討する。製品名だけで通知と阻止の実行を判断しない。
判断に使う場面: まず通信の可視化と通常時の把握が必要なら、監視点・暗号化の制約と通知先を決めてIDSの受動監視を評価する。通知を誰も見ない構成は避ける。
端末・SOC
EDRは端末を中心に検知・調査・対応を支え、XDRは複数の領域の信号を関連付けて調査・対応を支える。XDRはEDRを含み得るため、単純な上位互換への買い替えではない。端末対応の不足が中心ならEDRの運用を整え、メール・ID等をまたぐ調査が課題なら連携条件を揃えてXDRを比較する。
判断に使う場面: 端末の未登録、センサー停止、通知先不明、隔離承認の未整備が中心なら、XDRの購入より先に現在のEDR運用の不足を埋める。
ネットワーク・クラウド
公開WebやAPIでHTTPリクエストを検査するならWAF、管理ポートや内部区画への到達を制限するならネットワークファイアウォールを使います。公開サイトと管理経路を同じ基盤で持つなら、両方の役割を設計します。WAF導入時はオリジンへの別経路、本文検査の上限、正規操作の誤遮断を確認します。
判断に使う場面: 公開フォームやAPIでは、HTTPを検査できる位置にWAFを置きます。オリジンに届く経路を台帳と構成図で照合します。
ネットワーク・クラウド
UTMは中小組織向けに複数機能を一台に統合した製品、NGFWはアプリ識別とIPS統合を核に高性能・大規模向けの製品が多い。
判断に使う場面: 中小拠点ではUTMで運用負荷を抑える
認証・ID
SAMLとOIDCは、認証元の結果をアプリへ伝えるSSOの選択肢。SAMLはXMLのアサーション、OIDCはOAuth 2.0上のIDトークンを用いる。新旧だけで選ばず、接続先とSDKの対応、利用者の識別、認証結果の検証、鍵更新・復旧まで満たす方式を選ぶ。APIの業務権限は別に設計する。
判断に使う場面: 既存SaaSが必要な機能をSAMLでサポートし運用できているなら、規格の年齢だけを理由に移行しない。保守・要件・接続先の対応を確認して継続を判断する。
認証・ID
OAuth 2.0はAPIへのアクセスを認可する枠組みで、OIDCはOAuth 2.0の上に利用者の認証情報を伝える仕組みを加える。APIアクセスが目的ならOAuth、外部IdPの認証結果を受け取るログインならOIDCを検討し、業務上の認可はアプリ側でも確認する。
判断に使う場面: API連携だけが必要なら、OAuthで対象API・操作・権限・利用者の有無を先に決める。ログイン用の認証結果が必要ならOIDCを検討する。
認証・ID
パスワードは文字列の秘密を使い、パスキーは登録先に結び付く公開鍵の仕組みで認証する。対応サービスでパスキーを選ぶ際は、同期型かデバイス固定型か、利用者確認、紛失時の復旧と既存の認証手段まで確認する。パスキーを追加しただけでパスワード廃止・全セッション失効まで完了するとは扱わない。
判断に使う場面: 個人の重要アカウントで、対応環境と正規の復旧方法を確認できるならパスキーを検討する。未対応サービスでは固有のパスワードと利用可能なMFAを維持する。
認証・ID
HOTPはイベント(カウンタ)ベース、TOTPは時刻ベースのワンタイムパスワード。現在主流はTOTPで、Google Authenticatorなどが採用。
判断に使う場面: 一般的なアプリ MFA では TOTP を採用する
認証・ID
SSOは複数サービスへのログインを共通化し、MFAは異なる要素による本人確認を行う。代替する二者択一ではなく、SSOの認証元で必要なMFAを適用し、対象アプリ・利用者・例外と実際の結果を確認して組み合わせる。ログインできることと、業務権限が適切なことは別に確認する。
判断に使う場面: 複数SaaSの認証を統一したいならSSOを検討し、管理者や重要データに対しては必要なMFA方式と適用条件も決める。SSOの購入だけをMFA設定完了と扱わない。
認証・ID
サーバーセッションは通常IDから状態を参照し、JWTはクレームを表すトークン形式。JWT利用時も失効等の状態を持つ場合があり、保存・検証・認可の設計を分けて比較する。
判断に使う場面: Webサイトメインの利用は HttpOnly Cookie + サーバーセッションで十分
暗号・Web基礎
対称鍵暗号は同じ鍵で暗号化と復号を行い高速、公開鍵暗号は秘密鍵と公開鍵のペアで鍵共有と署名を担う。実際には組み合わせて使う。
判断に使う場面: TLSではハンドシェイクで公開鍵暗号、本体は対称鍵 (AES等) で暗号化
暗号・Web基礎
ハッシュは元データを復号するための仕組みではなく、暗号化は適切な鍵で内容を復元するための仕組みです。ログイン照合には専用のパスワード保存方式、後から読む機密データには暗号化を選びます。ハッシュ値だけでも候補の推測は可能で、単なるSHA-256一回やBase64を保護策にしません。
判断に使う場面: 自社サービスのログイン照合:保守中の認証基盤・ライブラリでパスワード専用方式を使い、ソルト・負荷・移行を確認する。
暗号・Web基礎
AESは対称鍵暗号で高速・データ本体向き、RSAは公開鍵暗号で鍵交換や署名向き。TLSや暗号メールでは両方を組み合わせて使う。
判断に使う場面: TLS では RSA/ECDSA で鍵交換、AES でデータ暗号化
暗号・Web基礎
TLSはSSLの後継で、SSL 2.0/3.0とTLS 1.0/1.1は使わない旧方式です。2026年のRFC 9852は新しいTLS利用プロトコルにTLS 1.3の既定利用を求め、1.2は条件付きの非既定オプションとします。既存環境の互換性、鍵交換・証明書・各通信区間も別に確認し、「SSL証明書」という商品名だけで接続の版を判断しません。
判断に使う場面: 新規・更新するWebサービス:TLS 1.3を優先し、TLS 1.2を残す必要がある場合は公式の暗号設定と対象クライアントを確認する。
暗号・Web基礎
http://はTLSによる保護を要求しないURL方式、https://はHTTP通信をTLSで保護するURL方式です。HTTPS化は通信の機密性・完全性と接続先の認証を支えますが、詐欺サイトや不正な依頼まで排除しません。運用では証明書だけで終えず、転送・内部の資源・業務機能・検索用URLとHSTSの影響を確認します。
判断に使う場面: 閲覧者:既知の正規URLから開き、ホスト名と警告を確認する。HTTPSだけで送金やパスワード入力の依頼を正当と判断しない。
脆弱性・リスク
脆弱性診断は脆弱性を網羅的に列挙する活動、ペネトレーションテストは攻撃者視点で実際に侵入可能かを検証する活動。
判断に使う場面: まずは定期診断で既知脆弱性を抑える
脆弱性・リスク
レッドチームは攻撃側として組織の検知・対応能力を試す役割、ブルーチームは防御側として検知・調査・封じ込めを担う役割。両者を統合運用するのがパープルチーム。
判断に使う場面: 年次でレッドチーム演習を実施し改善点を可視化する
脆弱性・リスク
脅威は損害を生む可能性のある事象や原因、脆弱性はその事象に対する弱点、リスクは目的・業務に対する悪影響を発生可能性と影響の大きさから捉えたもの。対象業務、既存対策、根拠と不確実性をそろえて評価し、脅威と脆弱性の単純な掛け算だけで結論を出さない。
判断に使う場面: 初めてリスク表を作るなら、資産名だけでなく「何が起き、どの弱点を通じ、業務に何が起きるか」を一文にする。脅威の一覧や脆弱性の件数を、そのまま優先順位表にしない。
脆弱性・リスク
KEVはCISAが実環境での悪用の証拠を確認した脆弱性のカタログ、EPSSは今後30日間に悪用が観測される確率の予測。過去の確認と将来の予測を競わせず、自社に対象があるか、到達できるか、業務影響は何かを照合する。低いEPSSやKEV未掲載を安全の証明にしない。
判断に使う場面: 自社に対象版があり、KEV掲載や信頼できる悪用情報があるなら、EPSSが低くても対応を下げる理由にしない。公開範囲・業務影響とベンダーの対処を確認し、必要な保護と調査を進める。
ネットワーク・クラウド
CSPMはクラウドの設定や権限の状態を評価し、CWPPはVM・コンテナなどのワークロードを保護します。誤公開や過剰権限の把握が課題ならCSPM、稼働中の脅威検知が課題なら対応するCWPP機能を確認します。CNAPPという名称だけで範囲を判断せず、対象クラウド・契約・収集方式・応答手順を照合してください。
判断に使う場面: 公開ストレージや過剰権限を把握したい場合は、CSPMの対象範囲と所有者への是正依頼を先に整えます。
ネットワーク・クラウド
VPNは通信のトンネル、ゼロトラストは接続先ごとに利用者・端末・権限を検証する設計です。認証連携と動作確認ができる業務からアプリ単位のアクセスへ移し、未対応の通信は接続先と権限を絞ってVPNに残します。切り替え前に正規の許可、条件外の拒否、障害時の復旧を確認します。
判断に使う場面: ブラウザの勤怠・申請アプリは、認証連携や端末条件を検証できるなら試験移行の候補にします。
ネットワーク・クラウド
SASEはネットワーク接続とセキュリティを統合して設計する考え方で、SSEはWeb・SaaS・社内アプリへのアクセス保護に焦点を当てます。既存WANを残してアクセス保護を見直すならSSE、拠点の接続・経路選択も更新するならSASEを検討します。人数や製品名より、対象経路・必要機能・運用責任・復旧条件で判断します。
判断に使う場面: 既存WANの更新予定がなく、WebとSaaSの保護を先に整えたい組織は、SSEの必要機能と接続経路を比較します。
ネットワーク・クラウド
リモートアクセスVPNは設定したネットワーク経路をトンネルへ通し、フォワードプロキシは指定されたアプリの通信を中継します。複数の業務アプリが社内宛先へ接続するなら組織指定のVPN、Web通信の中継・制御が目的なら管理されたプロキシが候補です。対象外のアプリ、DNSの経路、暗号化される区間を別々に確かめます。
判断に使う場面: 業務アプリが複数あり、社内の名前解決や内部ネットワークが必要なら、会社指定のVPNで対象経路を確認します。
ネットワーク・クラウド
DLPは機密データの利用・送信をポリシーで保護し、CASBはクラウド利用の可視化と制御を担います。メール・端末・SaaSのデータ取扱いが課題なら対応するDLP、SaaS利用や外部共有の把握が課題ならCASB機能を確認します。CASBのAPI検査と、通過中の通信を制御する機能を分け、対象経路・遅延・検査上限で使い分けます。
判断に使う場面: メールや端末からの送信を制御したい場合は、その場所と操作に対応したDLPを候補にし、分類から条件を決めます。
端末・SOC
マルウェアは悪意のあるソフトの総称、ウイルスはマルウェアの一種(自己複製してファイルに寄生するタイプ)。現代はランサムウェアやInfostealerが主流。
判断に使う場面: 報告書ではマルウェアと正確に表現する
端末・SOC
通常のフィッシングは不特定多数に同じメールを送る方式、スピアフィッシングは特定の個人や組織を狙って文面をカスタマイズした攻撃。
判断に使う場面: 受信メール側で DMARC/SPF/DKIM を強制する
キーワードを短くするか、カテゴリを「すべて」に戻してください。