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

費用ゼロで始めるセキュリティ対策10選

高田晃太郎
費用ゼロで始めるセキュリティ対策10選

Microsoftの分析では、多要素認証（MFA）の有効化により自動化されたアカウント侵害の 99.9% を阻止できると報告されています[1]。攻撃が高度化しても、まずは基本の徹底が最も費用対効果を生みます。CTOやエンジニアリングリーダーに求められるのは、追加コストなしで即日着手できる施策から始め、可観測性と復旧力まで一気通貫で底上げすることです。本稿では、実運用で使えるコード断片と設定例、そして意思決定を後押しする現実的な目安を交え、初日から動かせる10のアクションを体系的に整理します。対象はオープンソース、既存クラウドの無償機能、もしくは現在の契約内で賄える範囲に限定します。

アカウントと権限の初期防御を固める

不正アクセスの多くは資格情報の悪用から始まります。パスワード強度だけに頼るのは限界があり、まずはMFA（複数要素を組み合わせた認証）と最小権限（必要最小限の権限のみ付与）の組み合わせで入口のリスクを圧縮します[2]。MFAはTOTP（時刻ベースのワンタイムパスコード）アプリを使えばコストを増やさずに展開でき、主要なクラウドやSaaSはいずれも無償で設定を受け付けます。さらに、権限の棚卸しを週次または月次で回すだけでも攻撃面は縮みます。推奨の目安として、管理者権限のアカウント比率は全体の数%程度に抑え、鍵素材やAPIトークンの有効期限はおおむね90日程度を上限に統制するとよいでしょう。

MFAの全社必須化（TOTP）

Authenticatorアプリは無料で使えるため、導入障壁は運用だけです。IdP（アイデンティティプロバイダ）が無くても、GitHub、GitLab、AWS、GCP、各種VPNでTOTPを必須化できます。コードベースでは、管理系ツールのログインにTOTP検証を追加するだけでも効果があります。

# TOTP検証の最小実装例（pyotpの利用）
import os
import time
import pyotp

# 事前にユーザーごとに共有したベース32シークレット
USER_TOTP_SECRET = os.environ.get("TOTP_SECRET")

def verify_totp(token: str, window: int = 1) -> bool:
    totp = pyotp.TOTP(USER_TOTP_SECRET)
    return totp.verify(token, valid_window=window)

if __name__ == "__main__":
    user_input = input("Enter TOTP: ")
    print("OK" if verify_totp(user_input) else "NG")

ロールアウトは段階的に進めます。まず管理者、続いて生産環境へのデプロイ権限保持者、最後に一般ユーザーの順です。一般的な例として、数週間で大半（7〜8割程度）の有効化を目安にすると現実的です。周知、サポート窓口、バックアップコードの配布をセットで動かすと移行が滑らかになります。

最小権限の原則（IAMの過剰権限を解体）

過剰権限は被害の増幅器です。クラウドでは、読み取り専用や機能限定のカスタムポリシーへ置き換え、不要なワイルドカードを排除します。以下はS3の読み取り限定ポリシーの例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ]
    }
  ]
}

アクセス解析ツール（AWS IAM Access AnalyzerやGCP Policy Analyzer）は無料で使えます。直近90日間で一度も使われていない権限を優先的に外していくと、2〜4割程度の権限削減につながることが多く、事故時の横展開を抑えられます[3]。実務では、業務フローに沿って権限を職務単位へ集約し、定期棚卸しで新規・退職・異動を吸収するのが要点です。

アプリとインフラの露出を減らす

攻撃者に見える面を物理的・論理的に縮小します。OSレベルの自動更新、ファイアウォールのデフォルト拒否、Webヘッダの堅牢化は、可用性を落とさず即日実施できる代表格です。導入負荷は低く、効果は計測可能です。たとえばCSP（Content Security Policy: 外部リソースの読み込み元を制限するポリシー）の導入により、スクリプトインジェクションの成功率は実運用でも大幅に下がります[4]。反映後はエラーログの減少やブロック件数を観測し、短期間でインラインスクリプト検出が半減する程度を初期KPIの目安に据えます。

HTTPセキュリティヘッダ（HSTS, CSP, 他）

リバースプロキシやWebサーバにヘッダを一括付与します。HSTS（HTTPSのみを強制）、X-Frame-Options（クリックジャッキング対策）、X-Content-Type-Options（MIMEスニッフィング抑止）、Referrer-Policy（参照元情報の制御）などは副作用が少なく、まずはレポートオンリーでCSPを当て、本番でのブロックを安全に進めます。

# Nginxの例
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'" always;

導入後はブラウザのレポートとWAFログで効果を計測し、段階的にブロック運用へ移行します。公開エンドポイントの全てに適用することを目標にすると管理がシンプルです。

OSの自動更新（無停止に近い運用）

Ubuntuであればunattended-upgradesを有効化するだけです。メンテナンスウィンドウが取れるならカーネルも含めて適用範囲を広げます。

sudo apt-get update && sudo apt-get install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

// /etc/apt/apt.conf.d/50unattended-upgrades（抜粋）
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";

パッチ適用までの中央値を1〜3日以内に短縮できれば、既知脆弱性悪用のウィンドウを現実的に閉じられます。影響の大きい更新のみ手動審査にする運用も現実解です。

ホストファイアウォールのデフォルト拒否

ネットワークセグメントが限られていても、ホスト側のデフォルト拒否は有効です。SSHのみ許可し、アプリの露出ポートだけ明示的に開けます。

# ufwの例
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable
sudo ufw status verbose

攻撃面の縮小は外形監査でも可視化できます。nmapの検出ポート数が導入前後で半減する程度を狙い、例外はチケットで管理します。

ソフトウェアサプライチェーンを健全化する

依存関係の脆弱性、秘密情報の混入、コンテナの設定不備は、ビルド時に止めるのが最も安い対策です。OSSのスキャナとプレコミットフック、SBOM（Software Bill of Materials: ソフトウェア部品表）を組み合わせると、追加コストなしでCI/CDにセキュリティを組み込めます。ベースラインとして、依存スキャンで高深刻度の検出ゼロ、秘密情報スキャンで本番クレデンシャルの混入ゼロを継続KPI化します。

依存とコンテナの脆弱性スキャン（CI）

TrivyやGrypeは無料で使え、GitHub Actionsでも簡単に回せます。PRごとに結果をアノテーションし、深刻度が一定以上ならビルドを停止します。

# .github/workflows/security-scan.yml（抜粋）
name: security-scan
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Trivy FS scan
        uses: aquasecurity/trivy-action@0.20.0
        with:
          scan-type: fs
          severity: CRITICAL,HIGH
          format: table
          exit-code: 1
      - name: Build image
        run: docker build -t app:pr .
      - name: Grype image scan
        uses: anchore/scan-action@v3
        with:
          image: app:pr
          severity-cutoff: high
          fail-build: true

初期の検出は多くても、1〜2スプリントで重大な検出件数は大幅に減らせるケースが多いです。依存のアップグレード方針（自動更新と手動審査の棲み分け）を決めておくと運用が安定します。

秘密情報の混入防止（pre-commit）

リポジトリに鍵が入ると、事故は増幅されます。プレコミット（コミット前自動チェック）で防げば、CIで落ちる前に開発者体験を損なわずに止められます。以下はdetect-secretsとgitleaksの併用例です。

# .pre-commit-config.yaml（抜粋）
repos:
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.5.0
    hooks:
      - id: detect-secrets
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

既存履歴の走査はCIで行うとよいでしょう。

# 既存履歴のスキャン
gitleaks detect --source . --no-git -v

導入初期は誤検知の調整が必要ですが、運用に乗ると誤コミットはゼロを継続的に目指せます。検出ルールの例外管理と鍵の即時失効手順をあらかじめ文書化しておくと復旧が速くなります。

SBOMの生成と配布（Syft）

SBOMは調達・監査・インシデント対応の共通言語です[5]。Syftで生成し、アーティファクトと一緒に保存します。依存の透明性が上がれば、緊急パッチの初動時間を数時間規模に短縮できることがあります。

# SBOM生成（SPDX JSON）
syft packages dir:. -o spdx-json > sbom.spdx.json
# コンテナイメージの場合
syft packages docker:app:latest -o spdx-json > image.sbom.spdx.json

まずは生成の自動化から着手し、最終的に全サービスをカバーします。脆弱性データベースと紐づけたダッシュボード化まで進めると、優先度付けが容易になります。

可観測性とレジリエンスを底上げする

攻撃はゼロになりません。重要なのは、見逃さず、広がる前に抑え、迅速に復旧する力です。ここではOSレベルの監査、メールなりすまし対策、復旧手順の演習という、基本にして強力な三点セットを扱います。これらはインシデントの平均検知時間（MTTD）と平均復旧時間（MTTR）を現実に縮め、結果としてダウンタイムの合計を削減します。

OS監査ログ（auditd）で改ざんと横展開を検知

ファイルと特権操作の監査は、後追いの根拠と早期検知の両輪です。auditd（Linux標準の監査フレームワーク）は標準パッケージで導入でき、クリティカルなパスだけでも監査範囲に入れます。

# 監査ルール例（/etc/audit/rules.d/hardening.rules）
-w /etc/passwd -p wa -k passwd_changes
-w /etc/sudoers -p wa -k sudoers_changes
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_exec

まずはsudoersと重要設定の変更を確実に拾い、1週間ほど運用してノイズを絞り込みます。誤検知はおよそ一桁台を目安に抑え、アラート疲れを防ぐのがコツです。

SPF/DKIM/DMARCでなりすましを遮断

ドメインなりすましはフィッシングの起点になります。SPF（正規送信元の宣言）、DKIM（送信ドメイン署名）、DMARC（ポリシーとレポート）をDNSのTXTレコードで正しく設定すれば、追加コストなく配信ドメインの信頼性を高められます[6][7][8]。既存の送信経路を洗い出し、段階的にDMARCのポリシーを厳格化します。

# SPF（正規送信ホストを列挙）
example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.example.net -all"
# DKIM（公開鍵を掲示、秘密鍵はMTA側）
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."
# DMARC（初期は監視、のちに拒否）
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100"

メールヘッダの認証結果がpassに安定したら、p=quarantine、最終的にはp=rejectへ。社外成りすましの到達は体感として大幅に減ることが多く、ヘルプデスクの関連問い合わせも目に見えて落ち着きます。

復旧手順のドライラン（権限分離の検証）

バックアップのストレージ費用が別途かかる場合がありますが、手順の検証と役割分担の演習は低コストで実施できます。定期的に（例えば月次）読み取り専用アカウントで復旧手順をドライランし、RTO（目標復旧時間）は数時間程度を一つの目安に具体化します。実施記録を残すことで、監査対応と教育の双方に効きます。

導入の進め方と運用KPI

すべてを一度にやる必要はありません。現実的には、初週にMFA必須化、ヘッダ導入、プレコミット導入の三本柱を達成し、翌週にCIスキャン、OS自動更新、ホストFWへと広げていくのが負担の少ない進め方です。以降はSBOMの全体適用、DMARCの厳格化、監査ログのチューニング、権限の棚卸しを定常運用に落とし込んでいきます。KPIは施策に直結する指標で管理します。たとえば、MFA有効化率は数週間で大半の到達、公開エンドポイントのヘッダ適用は全面的に、nmapでの開放ポートは導入前比で半減を目安、重大脆弱性のCI検出はスプリントあたりゼロを目指し、秘密情報の誤コミットもゼロを継続目標とします。SBOMは全サービスをカバーし、DMARCは最終的にp=rejectへ。監査ログの誤検知は一桁台、RTOは数時間程度、管理者権限アカウント比率は数%程度を上限に保つ、といった設定が一般的です。

ROIの捉え方とチーム設計

本稿の10施策は追加コストを増やさず着手できますが、効果は定量で示してこそ意味を持ちます。たとえばヘッダ導入とMFA必須化により、インシデント起点の上位に挙がりがちなWeb露出と資格情報悪用に同時に圧力をかけられます。ダウンタイム1時間あたりの機会損失と、施策導入に要する工数を比較すれば、費用対効果は説明しやすくなります。実行体制は、プロダクトエンジニアとSRE/プラットフォームの小規模チームで数日単位のコミットから始め、運用定着後は短時間の定例レビューでKPIをダッシュボード監視する形が現実的です。

さらに学ぶ（内部リンク）

ゼロトラストの全体設計を知りたい場合、CI/CDにおける守りと攻めのバランス、ソフトウェア部品表の使いどころ、MFAの運用落とし穴、CSPのチューニング。

まとめ：今日の短い時間が、明日の事故を消す

費用をかけないという制約は、実は意思決定を速くします。MFA必須化、ヘッダ導入、プレコミットの三点は、今日からでも着手できます。次にCIスキャンとOS自動更新、ホストファイアウォールへと広げ、SBOM、DMARC、監査ログ、権限棚卸しを定常運用に組み込みましょう。数週間で、外形的な露出、内部の拡散経路、検知と復旧の遅れという三つのボトルネックは目に見えて小さくなります。あなたの組織では、どの施策から始めればKPIが最も動くでしょうか。まずはMFA有効化率、ヘッダ適用、重大脆弱性の検出ゼロという三つの目標を今週の到達点に置いてください。コストを増やさずとも、効果は着実に積み上がります。

参考文献

  1. Microsoft Security. One simple action you can take to prevent 99.9 percent of account attacks. 2019. 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/
  2. IPA 独立行政法人情報処理推進機構. アカウントの安全な利用（多要素認証の推奨を含む）. https://www.ipa.go.jp/security/anshin/account_security.html
  3. AWS. IAM Access Analyzer helps you identify unused access. 2023-11. https://aws.amazon.com/about-aws/whats-new/2023/11/iam-access-analyzer-inspecting-unused-access/
  4. OWASP Cheat Sheet Series. HTTP Headers Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html
  5. 経済産業省. SBOMの普及に関する取組（プレスリリース）. 2023-07-28. https://www.meti.go.jp/press/2023/07/20230728004/20230728004.html
  6. RFC 7208. Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. https://www.rfc-editor.org/rfc/rfc7208
  7. RFC 6376. DomainKeys Identified Mail (DKIM) Signatures. https://www.rfc-editor.org/rfc/rfc6376
  8. RFC 7489. Domain-based Message Authentication, Reporting, and Conformance (DMARC). https://www.rfc-editor.org/rfc/rfc7489