Amazon Inspector EC2 スキャンの有効化について

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか?」 というリスクの解説から、「どうやって直すのか?」 という具体的な修復手順(コンソール、AWS CLI、Terraformなど)まで、分かりやすく解説します。

この記事では、Amazon Inspector EC2 スキャンの有効化について、リスクと対策を解説します。

ポリシーの説明

Amazon Inspector v2は、EC2インスタンスに対して継続的かつ自動的な脆弱性スキャンを提供するマネージドサービスです。従来のInspector v1と異なり、エージェントベースとエージェントレスの両方のスキャン方式をサポートし、より包括的なセキュリティ評価を実現します。

Amazon Inspector v2は、EC2インスタンスに対して以下の包括的なスキャン機能を提供します:

  • パッケージ脆弱性スキャン: OSパッケージ(Amazon Linux 2/2023、Ubuntu、Debian、RHEL、CentOS、Windows Server等)やプログラミング言語パッケージ(Python、Java、Node.js、Ruby、Go等)のCVE(Common Vulnerabilities and Exposures)をリアルタイムで検出
  • ネットワーク到達性スキャン: インターネットからアクセス可能なポート、プロトコル、サービスの検出及び、セキュリティグループ、NACL、ルートテーブル設定の総合的な評価
  • ゼロデイ脆弱性への対応: 新しいCVEが公開されると、既存のインベントリを自動的に再評価

リスク

Amazon Inspector EC2スキャンが無効の場合、以下のようなセキュリティリスクが生じます:

  1. 未検出の脆弱性による侵害リスク: システムに存在する既知の脆弱性(Log4Shell、Spring4Shell、Heartbleedなどの重大な脆弱性を含む)が発見されず、攻撃者がこれらを悪用してリモートコード実行、権限昇格、データ窃取、ランサムウェア攻撃を引き起こす可胍性があります
  2. パッチ適用の遅延: 新しいCVEが公開されても(特にゼロデイ脆弱性)、影響を受けるインスタンスを特定できず、セキュリティパッチの適用が遅れ、攻撃者に悪用される時間的猶予を与えます
  3. 意図しないネットワーク露出: セキュリティグループの設定ミスによりインターネットから不要なポート(SSH:22、RDP:3389、MySQL:3306、PostgreSQL:5432、MongoDB:27017、Redis:6379等)がアクセス可能になっていても検出できず、不正アクセスやデータ漏洩のリスクが高まります
  4. コンプライアンス違反: PCI-DSS(要件11.2)、HIPAA Security Rule、SOC2、ISO 27001、NISTサイバーセキュリティフレームワークなどの規制要件では定期的な脆弱性評価と継続的な監視が必要とされており、これを満たせません
  5. インシデント対応の遅延: セキュリティインシデント発生時に、影響範囲の特定や原因究明が困難になります

修復方法

コンソールでの修復手順

AWSのコンソールを使用して、Amazon Inspector EC2スキャンを有効化します。

ステップ1: Amazon Inspectorサービスの有効化

  1. AWS管理コンソールにログインし、Amazon Inspectorサービスに移動します
  2. 初回利用の場合、「Get started」または「Inspector を有効化」をクリックします
  3. スキャンタイプの選択画面で以下を確認します:
    • 「Amazon EC2」にチェックが入っていることを確認
    • 必要に応じて「Amazon ECR」「AWS Lambda」も選択可能
  4. 「Activate Inspector」または「有効化」をクリックして有効化します
  5. 有効化には数分かかる場合があります

ステップ2: スキャンモードの設定(推奨:ハイブリッドモード)

  1. Amazon Inspectorコンソールで「設定」→「EC2 スキャン設定」に移動します
  2. 「Scan mode」セクションで適切なモードを選択します:
    • Hybrid(推奨): エージェントベースとエージェントレスの両方を使用
      • 最も包括的なカバレッジ
      • SSMエージェントがあるインスタンスは即座にスキャン
      • SSMエージェントがないインスタンスはスナップショット経由でスキャン
    • Agent-based: SSMエージェント経由でのスキャンのみ
      • コスト効率的
      • リアルタイムスキャン
    • Agentless: EBSスナップショットベースのスキャン
      • SSMエージェント不要
      • 追加コストが発生(スナップショット作成とスキャン)

ステップ3: SSMエージェントの設定(エージェントベーススキャンの場合)

  1. EC2コンソールで対象インスタンスを選択します
  2. インスタンスにSSMエージェントがインストールされていることを確認します
    • Amazon Linux 2/2023、Ubuntu、Windows Serverではデフォルトでインストール済み
    • その他のOSでは手動インストールが必要
  3. IAMロールに「AmazonSSMManagedInstanceCore」ポリシーがアタッチされていることを確認します
  4. Systems Managerコンソールで、インスタンスが「Managed instances」に表示されることを確認します
  5. SSMエージェントのバージョンが3.0.1124.0以上であることを確認します: sudo yum list installed | grep amazon-ssm-agent # または sudo systemctl status amazon-ssm-agent

注意:

  • エージェントレススキャンを使用する場合、SSMエージェントの設定は不要です
  • プライベートサブネットのインスタンスの場合、VPCエンドポイントの設定が必要です

ステップ4: スキャン結果の確認

  1. Amazon Inspectorコンソールの「Findings」セクションに移動します
  2. EC2インスタンスの脆弱性とネットワーク到達性の検出結果を確認します
  3. 重要度(Critical、High、Medium、Low)でフィルタリングして優先度の高い問題から対処します
    • Critical/High: 即座に対応が必要
    • Medium: 30日以内に対応を推奨
    • Low: 次回のメンテナンスで対応

Terraformでの修復手順

Amazon Inspector EC2スキャンを有効にするTerraformコードと、主要な修正ポイントを説明します。

# Amazon Inspector v2の有効化
resource "aws_inspector2_enabler" "main" {
  account_ids    = [data.aws_caller_identity.current.account_id]
  resource_types = ["EC2"]  # EC2スキャンのみを有効化
}

# 有効化の確認(データソース)
data "aws_inspector2_enabler" "status" {
  depends_on = [aws_inspector2_enabler.main]
}

# 委任管理者の設定(Organizations利用時)
resource "aws_inspector2_delegated_admin_account" "main" {
  count      = var.enable_organizations ? 1 : 0
  account_id = var.security_account_id
}

# 組織設定(Organizations利用時)
resource "aws_inspector2_organization_configuration" "main" {
  count = var.enable_organizations ? 1 : 0

  auto_enable {
    ec2         = true
    ecr         = false
    lambda      = false
    lambda_code = false
  }
}

# EC2インスタンス用のIAMロール
resource "aws_iam_role" "ec2_ssm_role" {
  name = "EC2-SSM-Inspector-Role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      }
    ]
  })
}

# SSM管理用のマネージドポリシーをアタッチ
resource "aws_iam_role_policy_attachment" "ssm_managed_instance_core" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
  role       = aws_iam_role.ec2_ssm_role.name
}

# インスタンスプロファイルの作成
resource "aws_iam_instance_profile" "ec2_profile" {
  name = "ec2-ssm-inspector-profile"
  role = aws_iam_role.ec2_ssm_role.name
}

# EC2インスタンスの例(SSM対応)
resource "aws_instance" "example" {
  ami                  = data.aws_ami.amazon_linux_2.id
  instance_type        = "t3.micro"
  iam_instance_profile = aws_iam_instance_profile.ec2_profile.name

  # メタデータサービスv2の強制(セキュリティベストプラクティス)
  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required"
    http_put_response_hop_limit = 1
  }

  user_data = <<-EOF
    #!/bin/bash
    # SSMエージェントのインストールと自動更新の有効化

    # OSの判定とSSMエージェントのインストール
    if [ -f /etc/os-release ]; then
      . /etc/os-release
      OS=$NAME
      VER=$VERSION_ID
    fi

    case $OS in
      "Amazon Linux"*)
        # Amazon Linux 2/2023(プリインストール済み)
        sudo systemctl enable amazon-ssm-agent
        sudo systemctl start amazon-ssm-agent
        ;;
      "Ubuntu"*)
        # Ubuntu
        sudo snap install amazon-ssm-agent --classic
        sudo systemctl enable snap.amazon-ssm-agent.amazon-ssm-agent.service
        sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service
        ;;
      "Red Hat"*|"CentOS"*)
        # RHEL/CentOS
        sudo yum install -y <https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm>
        sudo systemctl enable amazon-ssm-agent
        sudo systemctl start amazon-ssm-agent
        ;;
      *)
        echo "Unsupported OS: $OS"
        ;;
    esac

    # SSMエージェントの自動更新を有効化
    echo "2 0 * * * root yum update -y amazon-ssm-agent" >> /etc/crontab
  EOF

  tags = {
    Name        = "Inspector-Enabled-Instance"
    Environment = "Production"
  }
}

# VPCエンドポイント(プライベートサブネットのインスタンス用)
resource "aws_vpc_endpoint" "ssm" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.${data.aws_region.current.name}.ssm"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.vpc_endpoints.id]
  private_dns_enabled = true
}

resource "aws_vpc_endpoint" "ssm_messages" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.${data.aws_region.current.name}.ssmmessages"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.vpc_endpoints.id]
  private_dns_enabled = true
}

resource "aws_vpc_endpoint" "ec2_messages" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.${data.aws_region.current.name}.ec2messages"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.vpc_endpoints.id]
  private_dns_enabled = true
}

# Inspector用のS3エンドポイント(SSMエージェントのパッチダウンロード用)
resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${data.aws_region.current.name}.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = concat(aws_route_table.private[*].id, [aws_route_table.public.id])
}

# 検出結果の通知設定(EventBridgeを使用)
resource "aws_cloudwatch_event_rule" "inspector_findings" {
  name        = "inspector-critical-findings"
  description = "Capture critical Inspector findings"

  event_pattern = jsonencode({
    source      = ["aws.inspector2"]
    detail-type = ["Inspector2 Finding"]
    detail = {
      severity = ["CRITICAL", "HIGH"]
    }
  })
}

resource "aws_cloudwatch_event_target" "sns" {
  rule      = aws_cloudwatch_event_rule.inspector_findings.name
  target_id = "SendToSNS"
  arn       = aws_sns_topic.security_alerts.arn
}

# スキャン除外設定(リソースタグ)
resource "aws_ec2_tag" "inspector_exclusion" {
  for_each = var.excluded_instances

  resource_id = each.value
  key         = "InspectorExclusion"
  value       = "true"
}

# Inspector用のSuppression Rule(特定の脆弱性を除外)
resource "aws_inspector2_filter" "suppression_rule" {
  name        = "suppress-known-issues"
  action      = "SUPPRESS"
  description = "Suppress known false positives"

  filter_criteria {
    # 特定のCVEを除外
    vulnerability_id {
      comparison = "EQUALS"
      value      = "CVE-2023-12345" # 例:既知の誤検知
    }
  }

  filter_criteria {
    # 特定のタグを持つリソースを除外
    resource_tags {
      comparison = "EQUALS"
      key        = "Environment"
      value      = "Development"
    }
  }
}

最後に

この記事では、Amazon Inspector EC2 スキャンの有効化について、リスクと対策を解説しました。

Amazon Inspector v2によるEC2スキャンを有効化することで、継続的な脆弱性管理とセキュリティリスクの早期発見が可能になります。特にハイブリッドスキャンモードを使用することで、エージェントの有無に関わらず包括的なセキュリティ評価を実施できます。

重要なポイント:

  • Inspector v2はリアルタイムで継続的にスキャンを実行(最短15分間隔)
  • 新しいCVEが公開されると24時間以内に自動的に再評価
  • AWS Security Hubとの統合により一元的なセキュリティ管理が可能
  • Systems Manager Patch Managerと連携した自動修復が可能

ベストプラクティス:

  1. ハイブリッドスキャンモードの使用で包括的なカバレッジを確保
  2. Critical/High脆弱性は48時間以内に対処
  3. 定期的なスキャンレポートの確認(週次推奨)
  4. CI/CDパイプラインへのInspector APIの統合

この問題の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。 運用が非常に楽に出来る製品になっていますので、ぜひ興味がある方はお問い合わせお待ちしております。 最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。

参考情報

この記事をシェアする

クラウドセキュリティ対策実践集一覧へ戻る

貴社の利用状況に合わせた見積もりを作成します。

料金プランを詳しく見る