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

クラウドセキュリティの不安を解消する方法

高田晃太郎
クラウドセキュリティの不安を解消する方法

複数の業界調査は、クラウド事故の主因がクラウド提供側ではなく「顧客側の設定・運用」に偏っていることを示しています³。IBMの最新レポートでは、1件あたりのデータ侵害コストは約4.88百万ドルに達したと報告されています¹。また、Microsoftは多要素認証（MFA）の導入でアカウント侵害の約99.9%を抑止できると公表しています²。ここから読み取れるのは、最大の脆弱性はクラウドそのものではなく、設計と運用の凡ミスにあるという、実務上の明白な事実です。言い換えれば、不安の正体は制御可能な領域に残る曖昧さです。この記事では、その曖昧さを分解し、ゼロトラストと自動化を軸に、業務改善とシステム効率化を両立させる道筋を描きます。CTOやエンジニアリングリーダーが、経営目線のROIと現場の実装を一本の線でつなげられるよう、方針、設計、コード、運用の順に具体化していきます。

不安の正体を分解する：責任共有と攻撃面の現実

クラウドの不安は、責任共有モデル（クラウド提供者と利用者で分担する責任範囲）の境界が曖昧になる瞬間に生まれます。ハイパースケーラーが担保する物理層やハイパーバイザーの安全性は高水準ですが、アイデンティティ（ID）、設定、データ分類、鍵管理、ワークロード配置は利用者の責務です。攻撃者はここを突きます。特にIDがネットワーク境界の代替となる現在、アクセス権設計（IAM）と設定ミスが攻撃面を一気に広げます。マルチクラウドやSaaSが増えるほど、統一ルールが崩れ、例外が積み上がり、人的レビューでは追いつけなくなります³。結果として、公開設定のストレージ、過剰権限のトークン、長寿命のアクセスキー、暗号化されていないスナップショット、脆弱なイメージの横展開といった、起こるべくして起こる事故が繰り返されます。たとえば、誤設定のAzureコンテナにより約2,600万件の履歴書データが露出した事例が報告されています⁴。

典型パターンを言語化しておくと、防御の優先順位が明確になります。まず外部公開の可否を誤ったストレージと過剰権限のIAMは、攻撃者に最短経路を提供します。次に、ビルドパイプラインに埋もれた長寿命シークレットは、CIログや開発者端末の侵害を経由して実行権を奪われます。さらに、Kubernetesでの特権ポッドや署名のないイメージは、コンテナ境界を容易に越えさせます。最後に、監査証跡が分断された運用は、発見と封じ込めを遅らせ、コストを跳ね上げます。どれもツール単体の問題ではなく、設計の問題です。

事業インパクトを測る指標設計

セキュリティを業務改善とシステム効率化の文脈で語るには、技術指標を事業言語に翻訳する必要があります。平均検知時間（MTTD）と平均復旧時間（MTTR）をどれだけ短縮できたか、最小権限の適用率はどの程度か、禁止設定のドリフトを何日以内に是正できるか、監査対応における証跡収集の工数をどれだけ削減できたかを、四半期ごとに可視化します。アカウント侵害率の低下や重大アラートの偽陽性率の改善は、人的負荷の軽減と直結します。経営には、悪化時の潜在損失と改善時の回避コストを並べ、施策の妥当性を説明します。

守りを仕組みにする：ゼロトラストと最小権限の実装

抽象論で終わらせない鍵は、アイデンティティ中心設計と最小権限の自動付与・自動剥奪です。恒久キーを廃し、OIDC（OpenID Connect）で短命クレデンシャルを払い出し、権限は業務と時間で絞ります。ネットワークの許可リストに頼らず、条件付きアクセスとデバイスコンプライアンスでセッションごとに検証します。MFAは前提であり、可能ならフィッシング耐性の高いFIDO2（ハードウェア/プラットフォームベースの公開鍵認証）を第一選択にします⁵。

過剰権限と設定ミスをコードで封じる

まず、暗号化なしのアップロードを拒否するバケットポリシーを近接配置します。以下はS3に対する実用的なDenyポリシーの一例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnEncryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": ["AES256", "aws:kms"]
        }
      }
    }
  ]
}

次に、Kubernetesの入口で危険な設定を落とします。OPA Gatekeeperを用い、latestタグや特権ポッドを拒否するRegoは次の通りです（latestは再現性を損ない、特権は隔離を壊します）。

package k8srequired

violation[{
  "msg": msg
}] {
  input.review.kind.kind == "Pod"
  some c
  container := input.review.object.spec.containers[c]
  startswith(container.image, "")
  endswith(container.image, ":latest")
  msg := sprintf("disallow latest tag: %v", [container.name])
}

violation[{"msg": msg}] {
  input.review.kind.kind == "Pod"
  input.review.object.spec.containers[_].securityContext.privileged == true
  msg := "privileged container is not allowed"
}

TerraformやCloudFormationのレビューは、人手ではなくポリシーで行います。conftestで、S3のパブリック化やタグ欠落を拒否するRegoの例です。

package terraform.aws

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket_public_access_block"
  resource.change.after.block_public_acls == false
  msg := "S3 public ACLs must be blocked"
}

deny[msg] {
  res := input.resource_changes[_]
  res.change.after.tags == null
  msg := sprintf("tags required for %v", [res.address])
}

アカウント侵害の主戦場はIDです。条件付きアクセスでリスクを文脈化し、ハイリスクサインインをブロックします。Azure AD（現Microsoft Entra ID）のポリシー定義（概念モデル）を示します。

{
  "displayName": "Require MFA for risky sign-ins",
  "state": "enabled",
  "conditions": {
    "signInRiskLevels": ["high", "medium"],
    "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"]
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": ["mfa"]
  },
  "sessionControls": {"signInFrequency": {"value": 4, "type": "hours"}}
}

シークレットは置かないのが最善です。GitHub ActionsからAWSへの権限移譲はOIDCで行い、短命トークンを都度払い出します。ワークフローでのスキャンと合わせて示します。

name: iac-security
on: [push]
jobs:
  scan:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubOIDCRole
          aws-region: ap-northeast-1
      - uses: bridgecrewio/checkov-action@v12
        with:
          directory: ./infra

運用の健全性を定量化するために、公開リソースを継続監査するスクリプトを週次で走らせてもよいでしょう。boto3でパブリックなS3バケットを検出するスニペットは次のとおりです。

import boto3

s3 = boto3.client('s3')
resp = s3.list_buckets()
for b in resp['Buckets']:
    name = b['Name']
    pab = s3.get_public_access_block(Bucket=name)
    cfg = pab.get('PublicAccessBlockConfiguration', {})
    public = not all([
        cfg.get('BlockPublicAcls', True),
        cfg.get('IgnorePublicAcls', True),
        cfg.get('BlockPublicPolicy', True),
        cfg.get('RestrictPublicBuckets', True)
    ])
    if public:
        print(f"Public risk: {name}")

これらは個別のガジェットではなく一体の設計です。入口で拒否し、中で最小化し、出口で記録し、すべてをコードで再現可能にする。この原則が不安を小さくします。

可視化と自動化：CSPM/CNAPP/CIEMで継続的に下げる

ヒューマンレビューで設定ドリフトを追い続けるのは不可能です。CSPM（Cloud Security Posture Management）はクラウド横断の設定逸脱を、CNAPP（Cloud-Native Application Protection Platform）はビルドからランタイムの脆弱性と権限を、CIEM（Cloud Infrastructure Entitlement Management）はIDの過剰権限を可視化します。重要なのはダッシュボードの派手さではなく、SLOに結び付いたアクションの自動化です。高リスクの逸脱はチケットと修復プレイブックに直結させ、タグから責任チームに自動アサインします。リスク合算指標を定義し、週次での改善率を追うと、チームは成果を定量的に語れるようになります。

検知の品質も磨きます。偽陽性が多いアラートはノイズであり、応答時間を圧迫します。クラウドネイティブのログ（CloudTrail、Activity Logs、Audit Logs）を一元集約し、スキーマを揃えてクエリを標準化します。ルールはダッシュボードの裏側に押し込めず、リポジトリでバージョン管理し、テストを書き、変更をレビューします。これにより、セキュリティはプロダクトと同じ速度で進化できます。

ポリシーとエビデンスをコード化する

監査や取引先審査に強くなるには、証跡を即時に取り出せることが肝要です。変更管理、脆弱性管理、アクセスレビューの証拠は、ダッシュボードではなくデータレイクに残し、クエリで再現します。インフラの変更はPull Requestに紐付け、承認者や差分、適用時刻を機械的に追跡できるようにします。こうしておけば、SOC 2やISO 27001の要求に対しても、スクリーンショットの収集という非効率な作業から解放されます。結果として、監査対応のリードタイムが短縮され、プロジェクトの足止めが減り、実質的な開発時間が増えます。

ガバナンスとROI：経営に効く運用のデザイン

セキュリティ投資の評価は、防いだインシデントという反実仮想に頼ると説明が難しくなります。そこで、回避コストと運用効率の二軸で語ります。侵害コストの統計値を上限とし、その何割を削減できたかを、MFAの普及率、最小権限の適用率、ドリフトの是正日数、検知応答の短縮、監査対応の工数削減といった観測可能な指標に落とし込みます。加えて、障害やインシデントがカスタマーサクセスやセールスに与える機会損失も含めれば、解像度は上がります。人の手がかかるレビューやエスカレーションが減れば、その分プロダクト開発のスループットが上がり、タイムトゥマーケット短縮として利益に跳ね返ります。

導入の現実性も大切です。最初の月は可視化に全振りし、ゾーンごとのリスクを測ります。次の月は入口（IDとCI）での強制に着手し、最後の月は運用のSLOと自動修復の整備に充てる。三か月で目に見える成果が出ます。途中で「例外」が出てきたら、期限付きとし、責任者と失効日をタグに刻みます。例外の棚卸しは儀式ではなくシステムに組み込むものです。すべてが回り始めたら、次はビジネス連携です。新規プロダクトの立ち上げテンプレートに、最小権限のロール、暗号鍵、監査設定、リスク受容の承認フローをプリセットし、開発が安全なデフォルトから始まるようにします。セキュリティは止めるためではなく、速く・安全に進むためのプロダクト機能として提供します。

内部連携と学習の仕組み

実装を持続可能にするには、現場が使える言葉で合意を作ることです。SRE、プラットフォーム、アプリ、セキュリティの各チームで共通の語彙を持ち、逸脱は責める対象ではなく学習の材料として扱います。ポストモーテムを定期的に公開し、対策は再発防止の観点で仕組み化します。これにより、個人ではなくシステムが賢くなり、不安は徐々に設計可能なリスクへと変わっていきます。

まとめ：不安は設計に変えられる

クラウドの不安は、責任の境界と設定の曖昧さから生じます。ゼロトラストと最小権限を出発点に、「入口で拒否し、中で最小化し、出口で記録する」という原則をコードと自動化に落とし込めば、攻撃面は目に見えて縮みます。Microsoftのデータが示すMFAの約99.9%という抑止力²や、設定ミスが事故の大半を占めるという業界の実態³を、抽象論ではなく日々のパイプラインとポリシーに翻訳してしまうことが、実務の勝ち筋です。三か月で可視化、強制、運用の順に整えれば、MTTDとMTTRは短縮され、監査対応の待ち時間は減り、開発のスループットが上がります。次にどこから始めますか。未採用の領域があるなら、今日ひとつの例外を期限付きに置き換えてみてください。小さな一歩が、チーム全体の安全な速度を底上げします。

参考文献

  1. IBM Newsroom. IBM report: Escalating data breach disruption pushes costs to new highs (2024-07-30). https://newsroom.ibm.com/2024-07-30-ibm-report-escalating-data-breach-disruption-pushes-costs-to-new-highs
  2. Microsoft Security Blog. One simple action you can take to prevent 99.9 percent of account attacks (2019-08-20). https://www.microsoft.com/en-us/security/blog/2019/08/20/one-simple-action-you-can-take-to-prevent-99-9-percent-of-account-attacks/
  3. ZDNET. 99 percent of all misconfiguration in the public cloud go unreported. https://www.zdnet.com/article/99-percent-of-all-misconfiguration-in-the-public-cloud-go-unreported/
  4. ITPro. 26 million CVs were exposed when a recruiting software firm left a misconfigured Azure container open. https://www.itpro.com/security/data-breaches/26-million-cvs-were-exposed-when-a-recruiting-software-firm-left-a-misconfigured-azure-container-open-cybersecurity-experts-warn-its-an-easy-mistake-thats-becoming-far-too-common
  5. FIDO Alliance. NIST cites phishing resistance of synced passkeys in digital identity guidelines update. https://fidoalliance.org/nist-cites-phishing-resistance-of-synced-passkeys-in-digital-identity-guidelines-update/