はじめに
この記事を3行で
- クラウドの普及により個々のデバイスに対する「エンドポイントセキュリティ」が主流となっている
- AWSサービスであるInspector/System Manager/GuardDuty は「防御・検知」をカバー
- EDRによりEC2への脅威にリアルタイム対応が実現でき、24/365で専門チームが監視・対応を代行するMDR製品も登場している
想定読者
- AWSの導入を検討中、またはAWSを利用しておりセキュリティ対策を検討している方
- クラウド環境におけるセキュリティ対策の実行や、具体的なサービスの選び方に迷っている方
記事の目的
この記事は筆者が以下を整理するにあたって調査した内容をまとめたものです。同様の疑問がある方のお役にたつと幸いです。
- エンドポイントセキュリティとは何か（従来型との違い）
- AWS（特にEC2）でエンドポイントセキュリティを実現する方法
- エンドポイントセキュリティに関連するサービス/製品の機能の違い
※出典元を明記している画像を除いて、本記事で使用している画像は生成AIによって生成した画像です。
クラウドの「エンドポイントセキュリティ」とは？
エンドポイントセキュリティの解説が不要な方は AWSにおける「エンドポイントセキュリティ」 からお読みください。
「エンドポイントセキュリティ」とは具体的に何を刺すのでしょうか？エンドポイントセキュリティについてAWSのサイトに解説ページがあるので引用させていただくと、
デスクトップ、ノートパソコン、携帯電話などのエンドユーザーデバイスを悪意のある望ましくないソフトウェアから保護する一連のプラクティスとテクノロジーです
出典：https://aws.amazon.com/jp/what-is/endpoint-security/
とあります。
また「エンドポイント」に該当するものとして、パソコンや携帯電話の他、サーバーやルーター、プリンター、スキャナー、コピー機などの周辺機器、IoTデバイスなどが挙げられています。つまりエンドポイントセキュリティとは、「システムを構成するサーバー」と「システムに繋がる全ての端末」に関するセキュリティと言えるでしょう。
エンドポイントセキュリティとは
システムを構成する／システムに接続される全てのデバイスのセキュリティ
オンプレミスによるシステム開発では「エンドポイントセキュリティ」という単語はあまり登場しませんでした。しかし、クラウドサービスの利用やリモートワークが普及してきたことで、それまで気にされていなかったシステムの外にある要素へのセキュリティ対策が必要になり、重要性が高まっています。
従来のウイルス対策と境界防御
「エンドポイントセキュリティ」以前のセキュリティは、内部ネットワークと外部ネットワークを明確に分け、その境界にファイアウォールなどのセキュリティ製品を配置する「境界防御」が基本でした。しかしクラウドサービスやリモートワークが多くなってきたことで、内部ネットワークのみに存在していた「情報資産」や「システムの利用者」がネットワークの外にも存在することが増えています。
- ハイブリッド構成のシステム：
- オンプレミス <-- ネットワーク --> クラウドサービス
- リモートワーク環境：
- 複数のリモート用PC <-- ネットワーク --> 社内サービス
このように境界自体が曖昧となった結果、ネットワークの境界を守るのではなく、個々のデバイス単位でセキュリティ対策を行う「エンドポイントセキュリティ」 が注目されています。
AWSにおける「エンドポイントセキュリティ」
AWSにおける「エンドポイント」のサービスとしては以下が考えられます。
- Amazon EC2：仮想サーバー
- Amazon WorkSpaces：仮想デスクトップ
- AppStream 2.0：デスクトップアプリケーションの配信
- AWS Lambda：サーバーレスなプログラム実行環境
AWSでは「エンドポイント」というと、「VPC Endpoint」などの接続先を意味するケースがあります。
この記事では「エンドポイントセキュリティ」の文脈における、コンピューティングデバイスという意味で「エンドポイント」を用います。
責任共有モデルに基づくと、特にEC2については私たち利用者がセキュリティ対策を考え、実施していく必要があります。
AWSユーザーは知っておくべき「責任共有モデル」
「責任共有モデル」とは、AWSを利用する上で重要なセキュリティの考え方です。責任共有モデルでは、AWSは「クラウド自体のセキュリティ（データセンターの物理的保護やネットワークインフラ）」に責任を持つ一方で、「クラウド内のセキュリティ」はユーザー自身の責任で管理することが求められます。
EC2を利用するのであれば、OSやミドルウェアのアップデート、パッチ適用、アンチウイルスソフトの導入などを利用者の責任のもとに管理する必要があるということになります。
出典：責任共有モデル
https://aws.amazon.com/jp/compliance/shared-responsibility-model/
LambdaやWorkspacesなどの場合は、OSのアップデートやセキュリティパッチ適用などの運用部分をAWSが管理するため、セキュリティに関するインフラ管理を利用者が考える必要はありません。このように運用部分もサービスに含まれているものを「マネージドサービス」と呼び、マネージドサービスを積極的に利用することもセキュリティ対策の1つとなります。
出典：AWS Lambda の責任共有モデル
https://docs.aws.amazon.com/ja_jp/whitepapers/latest/security-overview-aws-lambda/the-shared-responsibility-model.html
とは言え、マネージドサービスはAWSが管理する範囲が広くなる分、サービスを利用する場合の制約も増えます。例えば、Lambdaは1回のリクエストで実行できる処理時間の上限は15分となっており、処理時間が15分以上かかるようなプログラムは実行できません。(※)
現実的にはEC2を利用した方がよいケースもありますので、そういったケースを想定して、EC2のエンドポイントセキュリティについて考えたいと思います。
※ Lambdaの実行時間については、re:Invent 2025で発表された「Lambda Durable Functions」により考え方が少し変わります。（とはいえ、制限はまだあります）
Lambda Durable Functionsについては、@___nix___ さんの素晴らしい記事をご参照ください。
Lambda Durable Functions で15分の制限時間問題を回避してみる
AWSのセキュリティサービスがカバーする範囲＝事前の防御・検知
EC2のエンドポイントセキュリティに関連するサービスとしては「Amazon Inspector」と｢AWS System Manager｣、「Amazon GuardDuty」が挙げられます。
それぞれ、サービス概要は以下の通りです。
- Amazon Inspector
- EC2のOS・ソフトウェアの脆弱性スキャン
- 意図しない外部ネットワークへの露出がないかをチェック
- AWS System Manager
- 「Patch Manager」により自動でパッチを適用
- Amazon GuardDuty
- AWSサービスのログを機械学習で分析し、不審なふるまい・悪意ある通信・異常なアクセスパターンを検知
上記のとおりAWSのネイティブサービスを利用することで、EC2内の脆弱性の発見、パッチ適用の自動化、不審な通信や挙動の検知などが可能です。代表的なセキュリティのフレームワーク(*)に当てはめると、これらのサービスの機能は「防御」と「検知」に該当します。
このように整理すると上記のAWSサービスでは、インシデントが発生した際の｢対応｣はカバーされていないことが分かります。
サイバーセキュリティフレームワーク
米国国立標準技術研究所（NIST）が策定した、組織がサイバーセキュリティリスクを特定・管理・軽減するためのガイドラインのことです。セキュリティ対策を以下の6つの機能ごとに体系的にまとめています。
- 統治 (2.0で追加)
- サイバーセキュリティリスク管理の監督と戦略を確立する
- 識別
- 社内の資産（システム、データなど）、ビジネス環境、ガバナンス、リスク評価、サプライチェーンを整理し、それらの優先順位付けを行う
- 防御
- サイバー攻撃を未然に防ぎ、システムやデータを保護するための対策
- 検知
- インシデントの発生を早期に特定するためのプロセス・機能
- 対応
- 検知されたインシデントの対する事前の計画や実際の分析・対処
- 復旧
- セキュリティインシデント後に損なわれたシステムや運用を回復させるための活動
AWSサービスがカバーしていない範囲＝インシデントへのリアルタイム対処
AWSサービスのセキュリティ機能は基本的に防御と検知です。AWS Config ルールという機能を使えば、「セキュリティグループの設定が変更されたら自動で元に戻す」といった設定レベルの自動修復は可能です。
しかし、これはあくまで｢設定の維持｣であり、ウイルス感染といった「脅威への対応」ではありません。例えば、正規のルートで侵入したランサムウェアがOS内部でファイルの暗号化を始めた場合、AWS Configでは検知も停止もできません。
このような 「OS内部で発生する動的な脅威」にリアルタイムで対処するためには、専用の仕組みが必要です。
エンドポイントで発生したセキュリティインシデントを検知し、迅速に対応する製品をEDR(Endpoint Detection and Response)と呼びます。EDRとAWSの各種セキュリティサービスを比較すると、以下の通りEDRでは対応の部分がカバーされていることが分かります。
| 機能 | AWS Inspector | AWS Systems Manager | AWS Config | Amazon GuardDuty | 一般的なEDR |
|---|---|---|---|---|---|
|
脆弱性スキャン (OS・アプリ) |
◎ 網羅的 |
〇 パッチ適用状況確認 |
× | × | 〇 (対応している製品が多い) |
|
構成管理・修復 |
△ NW到達性の検知のみ |
△ パッチ適用のみ |
◎ 構成の監視・修復 |
× | △ OS設定の監視・管理のみが多い |
|
脅威検知 (ログ・通信) |
× | × | × |
◎ ログ分析・異常検知 |
〇 プロセスの挙動解析 |
|
脅威への対応 (実行ブロック) |
× | × | × | × |
◎ プロセス停止・隔離 |
一方で、EDRだけではカバーしきれない部分もあります。EC2のエンドポイントセキュリティを実現するためには、AWSサービスに加えてEDRも導入するべきでしょう。実際、AWSのエンドポイントセキュリティの解説ページでも、以下の通りサードパーティ製品について言及されています。
AWS はエンドポイントセキュリティをどのようにサポートできますか?
AWS Marketplace で利用可能な エンドポイントソリューションは、エンドポイントアセットを管理および設定し、バグ、マルウェア、および不注意によるデータ開示からそれらのアセットを保護するのに役立ちます
出典：https://aws.amazon.com/jp/what-is/endpoint-security/
AWSのエンドポイントセキュリティはAWSサービスによる対策だけでOK？
AWSサービスがカバーする範囲は｢防御｣と｢検知｣であり、
マルウェア感染などの脅威への対応にはサードパーティのEDR製品による対策が有効
エンドポイントセキュリティ製品の選び方
ではEDRを導入するとして、どの製品を選ぶべきでしょうか。
EDRに限らずですが、製品導入を検討する際には機能だけでなく、予算や導入する環境への適合性（クラウドのみか・オンプレミスも含めるか等）、人材のスキルを踏まえた導入/運用の負荷なども検討する必要があります。これらの検討項目についても少し整理してみましょう。
動作環境
自社のシステム環境全体をカバーできるかという点は重要です。EC2では複数のOS（Amazon Linux 2/2023, Windows Server, Ubuntu等）が利用できるため、自社で利用しているOSがサポートされているか確認する必要があります。またAmazon ECS/EKSを使ってコンテナを利用している場合、コンテナ内部のランタイム保護に対応しているかもポイントとなります。
ハイブリッド構成となっている場合は、オンプレミスの物理サーバーや仮想環境（VMware/Hyper-V）も同一のコンソールで管理できる製品が望ましいでしょう。
導入の容易性
多数のサーバーに手動でエージェントをインストールするのは現実的ではありません。AWSの場合は、Systems Manager (SSM) Distributorを用いた一括配布や、EC2のゴールデンイメージ（AMI）への組み込みによって簡単にエージェントが導入できるため、EDR製品がそういった方法に対応しているかを確認しましょう。AWS統合されたSaaSの場合、エージェントレスで導入できる製品もあります。
運用のサポート体制
見落としがちなポイントとして、日本語対応の質と範囲があります。 海外製の優れたセキュリティ製品であっても、管理画面やマニュアルが英語のみであったり、サポートのレスポンスに時差があったりする場合、緊急時の初動対応に遅れが生じるリスクが考えられます。日本の商習慣に対応できるサポート体制があると、なお安心でしょう。
運用負荷を解決する「MDR（マネージドサービス）」
高機能なEDRツールを導入しても、それを使いこなせなければ意味がありません。EDRは日々多くのアラートを発しますが、その中から「本当に危険なもの」を見極め、適切に対処するには高度な専門知識が必要です。
そこで最近MDR（Managed Detection and Response）が注目されているようです。MDRでは、24時間365日体制でセキュリティの専門家による監視・対処をサービスとして提供されます。「専任のセキュリティ担当者がいない」「夜中や休日まで体制を用意できない」という企業向けのソリューションです。
まとめ
AWSの責任共有モデルを踏まえると、EC2を利用する場合はOS層より上のセキュリティは利用者がその管理の責任をもちます。セキュリティの実装を支援するために、AWSサービスとしてはSystem ManagerやInspector、GuardDutyといったサービスが提供されます。これらのサービスによる防御・検知に加え、脅威へのリアルタイム対応が可能なEDRを導入することで、より強固なセキュリティを実現できるでしょう。
一方で利用者が管理しなければいけない全ての範囲に対し、継続的な監視や対応を自社だけで行うのは現実的ではないケースもあります。そういった場合には、MDRによって運用を外部の専門家に任せるというアプローチは選択肢の一つになるでしょう。