会社情報
採用情報
お問い合わせ
Article

クラウドサービスのセキュリティチェック項目

高田晃太郎
クラウドサービスのセキュリティチェック項目

IBMのCost of a Data Breach（2024）では平均被害額が約4.88百万ドルと報告され、為替次第では数億円規模の損失に相当します¹。さらにGartnerは、クラウドにおけるセキュリティインシデントの多くが利用者側の設定不備で生じると繰り返し指摘しています²。Verizon DBIR 2024でも人的要因が多数の侵害に関与し、盗まれた認証情報の悪用が主要因であることが示されています³。公開事例や一般的なインシデントレビューを見ると、被害の出発点は高度なゼロデイよりも、公開設定、過剰権限、ログ未整備といった“見える失敗”であることが少なくありません。だからこそ、チェックリストを作ること以上に、チェックを継続稼働させる仕組み化が投資対効果に直結します。本稿ではExcelの点検表を超えて、Policy as Code（ポリシーのコード化）と運用のループで回す前提のクラウドセキュリティチェック項目を、実装の最小例とツール選定の要点まで整理して解説します。

失敗しない前提：チェックはコードで回す

チェックを人手に依存すると、開発スピードか品質のどちらかが毀損します。IaC（Infrastructure as Code）への静的解析、稼働中のクラウド実リソースに対する継続的評価、そして違反時にデプロイを止められるCIゲート（パイプライン進行の停止条件）が揃って初めて、運用コストを抑えつつリスクを一定以下に制御できます。目安として、TerraformやKubernetesマニフェストに対してCheckovやConftestをパイプラインへ組み込む場合、CIの延伸は環境や規模にもよりますが数十秒から数分程度に収まることが多く、コードレビューの認知負荷を安定して下げられます。

OPA/RegoとCIで公開設定を未然にブロックする

たとえばS3やオブジェクトストレージの公開設定を未然にブロックするには、OPA（Open Policy Agent：汎用ポリシーエンジン）で用いるRego（ポリシー言語）で「公開は禁止」というルールを明示し、ConftestでIaCの差分をテストします⁴。違反時にCIを失敗させ、レビュー工程に判断を持ち込まないのが肝要です。

package storage

deny[msg] {
  input.resource.type == "aws_s3_bucket"
  input.resource.acl == "public-read"
  msg := "S3 bucket must not be publicly readable"
}

deny[msg] {
  input.resource.type == "google_storage_bucket"
  input.resource.public == true
  msg := "GCS bucket must not be public"
}

CIにConftestとCheckovを組み込み、ポリシー違反やCIS準拠違反を機械的に検出します。以下はGitHub Actionsでの最小構成例です。

name: iac-security
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@v12
        with:
          directory: .
          soft_fail: false
      - name: Install conftest
        run: |
          curl -L https://github.com/open-policy-agent/conftest/releases/download/v0.52.0/conftest_0.52.0_Linux_X86_64.tar.gz \
          | tar xz && sudo mv conftest /usr/local/bin/
      - name: Conftest (OPA/Rego)
        run: conftest test -p policy/ ./terraform

クラウド側の継続評価も必須です。CSPM（Cloud Security Posture Management：構成管理の継続評価）であるAWS Security Hub、AzureのDefender for Cloud、GCP Security Command Centerなどを有効化し、検出を通知で終わらせず、運用SLO（Service Level Objective）に紐づけて是正までのリードタイムを測定します。Terraformで基盤の検出サービスを一括有効化しておくと、新規アカウントでも取りこぼしが防げます。

resource "aws_guardduty_detector" "main" {
  enable = true
}

resource "aws_securityhub_account" "this" {}

resource "aws_securityhub_standards_subscription" "cis" {
  standards_arn = "arn:aws:securityhub:::standards/cis-aws-foundations-benchmark/v/1.4.0"
}

アイデンティティとデータ保護の最重要項目

侵害の多くは認証情報の悪用から始まります。したがって最初に投資すべきは、SSO（シングルサインオン）とMFA（多要素認証）の強制、過剰権限の削減、そしてデータの暗号化です。手作業の棚卸しに頼るのではなく、権限境界やタグ、条件付きポリシーを組み合わせ、そもそも過剰権限が発行されにくい設計に寄せます。暗号化は保存時・転送時の双方で強制し、鍵の保護とローテーション（定期的交換）を運用ルールに組み込みます⁴。

MFA必須とTLS強制は「否定のポリシー」で確実に

IAMでは明示的Denyを用いてMFA未使用時の操作を拒否し、オブジェクトストレージではTLSでないアクセスを拒否します⁴。否定のポリシーは例外に強く、スケールする運用に向きます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRequestsWithoutMFA",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ],
      "Condition": {"Bool": {"aws:SecureTransport": "false"}}
    }
  ]
}

鍵管理ではKMSやCloud KMSのキーポリシーを最小権限（必要最小限のアクセス）で定義し、使用主体を役割（ロール）に限定します。監査上は、鍵の使用ログとローテーション実績が問われやすいため、回数や間隔をSLO化して可視化しておくと、審査対応の負担を下げられる可能性があります⁷。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowUseForAppRole",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:role/app-role"},
      "Action": ["kms:Encrypt","kms:Decrypt","kms:GenerateDataKey*"],
      "Resource": "*"
    }
  ]
}

データ発見と分類は後追いになるほどコスト高です。S3であればMacie、GCPではDLP、AzureではPurviewなどのツールで機微データを定期スキャンし、検出に応じて自動タグ付与や隔離を発火できるようにしておくと、設計と運用の両面での“漏れ”が減ります。

露出と侵入を最小化する運用設計

ネットワークはクラウドでも基本は同じで、到達性を絞り、境界を多層化し、例外の流通を止めることに尽きます。パブリックエンドポイントを極力避け、Private LinkやPrivate Service Connect等のプライベート経路を既定とし、WAF（Web Application Firewall）やDDoS保護を前段に置きます。KubernetesではNamespace、NetworkPolicy、Pod Security（PSA：Pod Security Admission）を基準に、コンテナイメージの署名検証とランタイム検知（例：Falco）までをセットで考えます。

Kubernetesはデフォルト拒否から始める

NetworkPolicyを適用しないクラスタは全方位に開放されます。まずは全拒否から、許可する通信だけを明示する形に切り替えます⁶。併せてIngress/Egressの可視化を行い、キャパシティプランニングと共通言語化しておくと、開発チームとの調整も短時間で済みます。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress: []
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              name: core-services
      ports:
        - protocol: TCP
          port: 443

オブジェクトストレージは公開事故が起きやすい領域です²。Terraformで暗号化と公開ブロックを標準化し、タグで例外の審査を自動化します。レビューのたびに議論するのではなく、“作れないから変えられない”状態を先に作ります⁴。

resource "aws_s3_bucket" "this" {
  bucket = "example-bucket"
}

resource "aws_s3_bucket_public_access_block" "pab" {
  bucket                  = aws_s3_bucket.this.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "sse" {
  bucket = aws_s3_bucket.this.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

コンピュート面では、EDR/CWPP（Endpoint Detection and Response / Cloud Workload Protection Platform）の導入で侵害後の横展開を早期に捕捉します。マネージドのSecurity HubやDefender for Cloud、GCP SCCに出てくるシグナルは、DatadogやSplunkなどのSIEM（Security Information and Event Management）に集約し、重複除外と抑止の自動化を進めます。Policy as Codeの詳細な実装は、各ベンダーのガイドやオープンソースのベストプラクティスを参照するとスムーズです。

可観測性とレスポンス：見える化から復旧まで

何かが壊れる前提で、発見から封じ込め、復旧に至る時間を短縮する設計が必要です。全アカウント・全プロジェクトで監査ログを強制有効化し、改ざん耐性のあるストレージに集約します。アラートは「誰が」「何分で」反応するかまで役割として定義し、ランブック（手順書）をコード化しておくと訓練と本番の差が縮みます。バックアップはRPO/RTO（目標復旧時点／目標復旧時間）で語られがちですが、年数回のリストア演習で“実際に戻る”ことを確認して初めて意味を持ちます。

監査ログの強制とアラートの自動化で初動を短縮

CloudTrailやAudit Logsを無効化できない仕組みにし、重要イベントに対しては自動でチケットやPagerを起動します。たとえばAWSでは、ルートユーザのコンソールログインやMFA解除の検知をメトリクス化し、しきい値に達した時点でオンコールを叩きます⁵。

resource "aws_cloudtrail" "org" {
  name                          = "org-trail"
  is_multi_region_trail         = true
  enable_log_file_validation    = true
  include_global_service_events = true
  s3_bucket_name                = aws_s3_bucket.this.id
}

SLO運用では「検出から封じ込めまでの中央値」「是正完了までの95パーセンタイル」を可視化しておくと、投資対効果の説明が容易になります。実務では、IaCスキャンの導入でレビューの手戻りが減り、デプロイまでのリードタイムが短縮する事例が報告されることもあります。復旧の観点では、スナップショットからの定期的な復元検証を自動化し、成功率と所要時間をダッシュボード化しておくことで、説明責任を定量的に果たしやすくなります。継続的モニタリング基盤の選び方や可観測性の詳細は、各クラウドの公式ドキュメントや業界ベンチマークの最新ガイドに当たるとよいでしょう。

運用計測とROI：止めるところで止める

セキュリティ投資はコストに見えがちですが、チェックをコード化してCIへ移すことで、レビューのやり直しや障害復旧の工数削減が期待できます。CheckovやConftestの導入でパイプラインの延伸は限定的に抑えつつ、リリース後の是正作業を減らす構えは、結果として総工数の圧縮につながりやすい。これは“完璧なセキュリティ”の追求ではなく、最小の待ち時間で最大の事故予防を実現する設計と言い換えられます。

まとめ

クラウドのセキュリティは、チェック項目を知ることよりも、それを毎回・自動で・例外なく実行する仕組みで決まります。公開設定の未然ブロック、MFAと暗号化の強制、観測とアラートの自動化、そして復旧の演習までが一連のループです。どこから始めるべきか迷うなら、まずはIaCに対する静的解析とRegoの最低限のルールをCIに組み込み、次にクラウド側のCSPMを有効化して是正のSLOを決める、という二段構えが効果と説明責任の両立に適しています。あなたのチームでは、どのチェックを今週コード化できそうでしょうか。小さな一歩でも、継続すれば大きな損失を避ける力になります。

参考文献

  1. IBM. Cost of a Data Breach Report 2024: average breach cost hits $4.88M. https://www.ibm.com/think/insights/whats-new-2024-cost-of-a-data-breach-report#:~:text=average%20breach%20hit%20a%20record%C2%A0,largest%20spike%20since%20the%20pandemic
  2. ComputerWeekly. Cloud misconfiguration a growing cause of security incidents (Gartner context). https://www.computerweekly.com/news/252504909/Cloud-misconfiguration-a-growing-cause-of-security-incidents#:~:text=Within%20the%20context%20of%20Gartner%E2%80%99s,%E2%80%9D
  3. Duo Decipher. Attacks based on credential theft on the rise, DBIR says (2024). https://duo.com/decipher/attacks-based-on-credential-theft-on-the-rise-dbir-says#:~:text=Attackers%20are%20more%20likely%20to,Malware
  4. AWS Documentation. Amazon S3 security best practices (blocking public access, requiring HTTPS). https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html#:~:text=Unless%20you%20explicitly%20require%20anyone,take%20to%20block%20public%20access
  5. AWS Architecture Blog. AWS CloudTrail best practices (organization trails, multi-account). https://aws.amazon.com/blogs/mt/aws-cloudtrail-best-practices/#:~:text=automatically,all%20AWS%20accounts%C2%A0in%20that%20organization
  6. Tigera Calico Docs. Kubernetes default deny network policy (beginner guide). https://docs.tigera.io/calico-cloud/network-policy/beginners/kubernetes-default-deny#:~:text=Here%27s%20an%20equivalent%20default%20deny,pods%20in%20the%20namespace%2C%20engineering
  7. AWS KMS Developer Guide. Apply least privilege to KMS keys. https://docs.aws.amazon.com/kms/latest/developerguide/least-privilege.html#:~:text=Since%20your%20KMS%20keys%20protect,IAM%20policies%20to%20IAM%20principals