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

最低限これだけはやるべきセキュリティ対策7選

高田晃太郎
最低限これだけはやるべきセキュリティ対策7選

公的な年次報告では、データ侵害が事業に与えるコストは数百万ドル規模に達し、封じ込めまでの期間も長期化しがちとされています¹。さらに、MandiantのM-Trends 2024は、侵入から発見までの滞在時間が短縮傾向にある一方、攻撃の初動は加速していると指摘しています⁴。すべてを同時に完璧にするのは現実的ではありませんが、事業継続とキャッシュフローを守るうえで、費用対効果の高い打ち手に絞ることはできます。本稿では、CTO・エンジニアリングリーダーが今日から進められる最低限の7施策を、実装の勘所と運用上の要点、そしてROIの観点で整理します。

事業インパクトを即時に下げる基盤対策

1. 身元を固める：MFAの全社必須化と例外管理

最初に着手すべきはアイデンティティの強化です。MFA（多要素認証）はアカウント侵害の抑止に大きく寄与すると広く報告されており³、少ない投資で効果が見込めます。導入のポイントは、従業員・請負を含む全アカウントでの強制、条件付きアクセスでの段階的適用、そして緊急用ブレイクグラスアカウントの厳格な隔離です。SaaSとIaaSの両方でMFAを“必須条件”にすることで、認証情報の漏洩が即座に致命傷になるリスクを抑えられます。実装レベルでは、たとえばAWSではMFA未使用時のアクションを一括拒否するセッションポリシーが有効です。

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

ブレイクグラスは物理的に分離した保管と定期的なリハーサルでのみ使用できる体制にします。予算インパクトはIDaaSのMFAオプション費用とFIDO2キーの配布が主で、費用対効果の高い投資です。

2. 触れられない権限設計：最小権限と特権アクセスの二重化

次に効くのは権限表面の圧縮です。クラウドでは、過剰付与のIAMロールが横展開の踏み台になりがち。新人から役員まで最小権限を原則とし、昇格は申請・承認・自動失効の三点セットで扱います。特権はPAM（特権アクセス管理）で時間制トークンを払い出し、監査ログとセットで保管します。マルチアカウント構成ではSCP（Service Control Policy）による“デフォルト拒否”が有効で、ワイルドカード権限の混入はCIで弾きます。OPA/Rego（ポリシー言語）による静的検査はレビューの人的負担を減らします。

package iam.validate

# Deny policies that contain Action "*" or Resource "*"
deny[msg] {
  some stmt
  input.Statement[stmt].Action == "*"
  msg := "IAM policy must not allow Action *"
}

deny[msg] {
  some stmt
  input.Statement[stmt].Resource == "*"
  msg := "IAM policy must not allow Resource *"
}

権限を絞るほど、侵害時の爆発半径は小さくなり、監査の発見可能性が高まります。運用工数は初期の棚卸しとCIゲート整備に寄りますが、以降は自動化で安定します。

3. 脆弱性を溜めない：パッチSLAと計測

重大脆弱性は時間との勝負です。ゼロデイ悪用の武器化は短期間で進むため、Criticalは数日以内、Highは1〜2週間以内といった現実的なSLA（合意された対応期限）を置きます。サーバは無人適用とメンテナンス枠の両建て、クライアントはリング配信で段階展開します。Ubuntu系なら無人アップデートを有効化し、SLA遵守率をメトリクス化します。

// /etc/apt/apt.conf.d/50unattended-upgrades（抜粋）
Unattended-Upgrade::Origins-Pattern {
  "origin=Ubuntu,codename=${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

開発では依存ライブラリのSCA（Software Composition Analysis）をパイプラインに組み込み、PR段階で差し戻します。GitHub DependabotやTrivyの組み合わせで、CVSS（共通脆弱性評価システム）やEPSS（悪用予測スコア）を閾値に自動ブロックする構成が運用しやすいでしょう。

侵入を前提にした検知・対応・復旧の強化

4. 可視化を先に整える：EDRと集中ログ（SIEM）

検知の早さは被害額に直結します。IBMの年次報告では、セキュリティAI/自動化の活用がコストや封じ込め時間の改善に寄与したと報告されています²。まずはEDR（Endpoint Detection and Response）で端末のふるまい検知を標準化し、IdP（認証基盤）、クラウド、SaaSのイベントをSIEM（Security Information and Event Management）に集約します。初期ルールは既知の侵害手口から始め、MTTD/MTTR（検知/復旧までの平均時間）を四半期で目標管理します。たとえばPowerShellの難読化実行は早期の異常検知に効くベーシックなルールです。

// Splunk SPL（疑わしいPowerShellの検知）
index=win sourcetype=WinEventLog:Security EventCode=4688 \
  NewProcessName="*powershell.exe" \
  (CommandLine="*EncodedCommand*" OR CommandLine="*IEX*" OR CommandLine="*FromBase64String*")
| stats count by AccountName, CommandLine, Computer, _time

ログの保管は、少なくとも数カ月のオンライン保管と約1年のアーカイブを目安にします。MDR（外部監視）の活用で夜間・休日の監視を補完すると、人的負荷と検知遅延の両方を抑制できます。

5. 止めない仕組み：バックアップ3-2-1と復旧演習

ランサムウェアの実態調査では、バックアップが直接狙われる傾向が複数報告されています⁶⁷。ゆえに、コピーの分離と不変化、そして復旧手順の訓練が要となります。3-2-1の原則（3つのコピー、2種類の媒体、1つはオフサイト）を実践するなら、オフラインまたはオブジェクトロックの併用が現実的です。クラウドではバックアップ計画をコード化し、復旧の成否をSLOで管理します。

# AWS Backup Plan（YAML例）
BackupPlan:
  BackupPlanName: prod-daily
  Rules:
    - RuleName: daily-immutable
      TargetBackupVaultName: vault-immutable
      ScheduleExpression: cron(0 18 * * ? *)
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:...:vault/offsite
          Lifecycle:
            DeleteAfterDays: 730

演習は定期的に行い、RPO/RTO（目標復旧時点/時間）を計測します。実務では、バックアップがあっても復旧できないケースが少なくありません⁸。バックアップがあるだけでは十分ではなく、リストアが計測可能で再現性があることをもって初めて備えと言えます。

ソフトウェア供給網と秘密の防御を標準装備に

6. 秘密を残さない：短命認証と集中管理

漏えい事故の多くはハードコードされた秘密情報から始まります。方針はシンプルで、長期鍵を避け、短命の一時クレデンシャルへ全面移行します。リポジトリには鍵を置かず、OIDCでクラウドにフェデレーションして権限を付与します。GitHub ActionsでAWSに短命アクセスする例を示します。環境に合わせてKMSとSecrets Manager/Vaultで回転・監査を一元化し、ローテーションは短い期限（数時間〜数日）を基準に定期運用します。

# .github/workflows/deploy.yml（抜粋）
name: deploy
on: [push]
jobs:
  run:
    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/gha-oidc-deploy
          aws-region: ap-northeast-1
      - run: aws sts get-caller-identity

Vaultのポリシーで発行期限を短く固定し、監査ログと紐づけておくと、インシデント時の追跡が速くなります。

# Vault policy（HCL例）
path "secret/data/app/*" {
  capabilities = ["create", "update", "read"]
}
path "auth/token/create" {
  capabilities = ["update"]
  allowed_parameters = {
    ttl = ["1h"]
  }
}

秘密の寿命を日単位から時間単位へ短縮するほど、漏えい時の悪用可能時間を大幅に短縮できます。

7. 作って守る：セキュアSDLCとSBOMの自動化

供給網リスクは、依存の連鎖と開発速度に比例して増えます。最低限のセットは、SAST/SCA/DASTの自動スキャン、依存のピン留め、SBOM（Software Bill of Materials）の生成、そしてPRゲートでの強制です。セキュリティを“止めるブレーキ”ではなく“早く安全に走るABS”に変えるには、CIに組み込み、失敗時は開発者に具体的修正ヒントを返す設計が肝です。以下はGitHub ActionsでCodeQLとTrivyを併用し、重大問題でPRを不可にする例です。

# .github/workflows/security.yml
name: security
on:
  pull_request:
    branches: [ main ]
jobs:
  codeql:
    uses: github/codeql-action/.github/workflows/codeql.yml@v3
  trivy-sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aquasecurity/trivy-action@0.20.0
        with:
          scan-type: fs
          format: 'sarif'
          output: 'trivy.sarif'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'
      - uses: anchore/sbom-action@v0
        with:
          output-file: sbom.spdx.json

パイプラインでの“落とし方”は、初期はHigh/Criticalのみを対象にしてリードタイムへの影響を抑えます。運用が安定したらMediumにも範囲を広げ、脆弱性の修正リードタイムをSLO化します。SBOMは顧客監査の応答時間を短縮し、調達やISO/ISMSの是正対応も合理化します。

実装・計測・改善を回すための運用知見

経営との共通言語を持つ：定量ターゲットと可視化

セキュリティは“感じ”ではなく数値で語ります。たとえば、MFA普及率の最大化、特権の有効期限の短縮、パッチSLA遵守率の継続的改善、MTTD/MTTRの短縮、RPO/RTOの明示、秘密の寿命短縮、SAST/SCAのブロック率と修正リードタイムの継続改善など、明確な目標値をダッシュボード化します。こうした指標の改善は、保険料や監査コストの低減、ベンダー見積の交渉材料にもつながります。

現実的なロードマップ：90日で「最低限」を固める

目安として、初月でMFA強制とブレイクグラス隔離、二ヶ月目で特権アクセスとパッチSLAの常態化、三ヶ月目でEDR/SIEMの主要ルールとバックアップ演習を整備し、同時並行で秘密の短命化とCIのセキュリティゲートを進めると、約90日で“底”ができます。以降は検知精度の向上、レッドチーム演習、資産・データ分類の精緻化へ拡張し、投資対効果の勾配を保ちながら成熟させます。

人の部分を軽視しない：模擬訓練と開発者体験

フィッシング模擬訓練やインシデント対応演習は、ユーザーの脆弱性を有意に低減することが示されています⁹。一方で、開発者が“壊れない”セキュリティ体験を得られるよう、ツールはIDEやPRコメントに統合し、ワンクリックで修正案に飛べるUXを整えます。現場の摩擦を減らすことが、結果としてセキュリティの底上げになります。

まとめ：7施策で作る「止まらない」標準

今日から進めるべき最低限の7施策は、身元を固めるMFA、権限を絞る最小権限、脆弱性を溜めないパッチSLA、早く気づくためのEDRとSIEM、事業を止めないバックアップ、秘密の短命化と集中管理、そして供給網を守るセキュアSDLCです。どれも単体で完璧である必要はなく、約90日で“底”を作り、以降は計測して改善するという発想が大切です。あなたのチームの現状で一番“効く”一手はどれでしょうか。まずはMFAの全社強制やブレイクグラスの隔離といった、費用対効果の高いところから始めてください。実装上の具体的な疑問があれば、内部リンクの各ガイドや、組織の開発・運用の文脈に合わせた評価記事を併せてご確認ください。次のスプリントの計画に、ひとつでも測れる施策を入れてみませんか。

参考文献

  1. IBM Newsroom. IBM Report: Escalating Data Breach Disruption Pushes Costs to New Highs (2024). https://newsroom.ibm.com/2024-07-30-IBM-Report-Escalating-Data-Breach-Disruption-Pushes-Costs-to-New-Highs
  2. IBM Newsroom. Use of AI/Automation cut costs by $2.88M and reduced containment time by 100+ days (2024 press release detail). https://newsroom.ibm.com/2024-07-30-ibm-report-escalating-data-breach-disruption-pushes-costs-to-new-highs#:~:text=Yet%20use%20of%20AI%2FAutomation%20cut,88%20million
  3. Microsoft Security Blog. One simple action you can take to prevent 99.9 percent of account attacks (2019). https://www.microsoft.com/security/blog/2019/08/20/one-simple-action-you-can-take-to-prevent-99-9-percent-of-account-attacks
  4. Google Cloud (Mandiant). M-Trends 2024 highlights: defenders continue to drive down dwell time (2024). https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2024
  5. Google Cloud (Mandiant). M-Trends 2024 (supporting details). https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2024#:~:text=that%20defenders%20are%20generally%20continuing,help%20drive%20down%20dwell
  6. TechRepublic. Ransomware attackers target backups (2023). https://www.techrepublic.com/article/ransomware-attackers-target-backups/
  7. CIO World Asia. 93 percent of cyberattacks target backup storage (2023). https://cioworldasia.com/2023/05/24/93-percent-of-cyberattacks-target-backup-storage/
  8. ZDNet Japan. バックアップから復旧できなかった理由の内訳など（2023）。https://japan.zdnet.com/article/35201507/
  9. HIPAA Journal. Study confirms security awareness training significantly reduces susceptibility to phishing attacks. https://www.hipaajournal.com/study-confirms-security-awareness-training-significantly-reduces-susceptibility-to-phishing-attacks/