0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

エンジニアが今日からできる情報漏洩対策チェックリスト10選【コード・コマンド付き】

0
Posted at

はじめに

情報漏洩というと「セキュリティ担当の仕事」と思われがちですが、実際の事故の多くは"開発者の日常の作業"から起きています。

  • APIキーをうっかりコミットした
  • デバッグ用のログに個人情報をそのまま出していた
  • 検証用のクラウド環境を公開したまま放置していた
  • エラー調査のために本番データを生成AIに貼り付けた

本記事では、エンジニアが"今日から手を動かせる"情報漏洩対策を、コード・コマンド付きのチェックリストとしてまとめます。

PD試験(プロフェッショナルデジタルスキル試験)の学習支援サイト「pds-siken.com」を運営しています。PD試験の科目Aでは、セキュリティが重点分野に指定され、セキュアな開発(SAST・SBOMなど)や生成AIのリスクも出題範囲に含まれています。
👉 PD試験 対策サイト pds-siken.com

チェックリスト全体像

# 領域 チェック項目
1 シークレット 認証情報をコードに書いていない
2 シークレット コミット前に秘密情報を自動検出している
3 シークレット 漏れたときのローテーション手順がある
4 ログ ログに個人情報・トークンを出力していない
5 クラウド ストレージを外部公開していない
6 クラウド 不要になった検証環境を削除している
7 権限 最小権限・短期間の認証情報を使っている
8 生成AI 機密情報・個人情報をAIに入力していない
9 端末 ブラウザに業務パスワードを保存していない
10 依存関係 ライブラリの脆弱性を継続的にチェックしている

順に見ていきます。

1. 認証情報をコードに書かない

APIキーやDBのパスワードをソースコードに直接書くのは、最もよくある漏洩原因です。

# NG:コードに直書き
API_KEY = "sk-xxxxxxxxxxxxxxxx"

# OK:環境変数から読み込む
import os
API_KEY = os.environ["API_KEY"]

ローカル開発で .env を使う場合は、必ず .gitignore に入れます。

.env
.env.*
!.env.example
*.pem
*.key

本番環境では、クラウドのシークレット管理サービス(AWS Secrets Manager、Azure Key Vault、Google Secret Manager など)を使うのが基本です。

2. コミット前に秘密情報を自動検出する

人の注意力には限界があるので、"仕組みで止める"のが確実です。gitleaks を pre-commit フックに組み込む例です。

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks:
      - id: gitleaks
pip install pre-commit
pre-commit install

これで、秘密情報を含むコミットはローカルで止まるようになります。既存リポジトリの履歴を一度スキャンしておくのもおすすめです。

gitleaks detect --source . -v

あわせて、GitHubのシークレットスキャンとプッシュ保護も有効にしておくと、二重のチェックになります。

3. 漏れたときは「削除」より「無効化」が先

秘密情報をpushしてしまったとき、慌ててコミットを消したくなりますが、"先にやるべきはキーの無効化・再発行"です。

  1. 該当するキー・パスワードをすぐに無効化し、新しいものを発行する
  2. そのキーで不正なアクセスがなかったか、アクセスログを確認する
  3. その後で、必要に応じて履歴から削除する

一度公開されたリポジトリの内容は、フォークやキャッシュ、自動収集ツールによって"すでにコピーされている"前提で考えます。

4. ログに個人情報・トークンを出さない

デバッグ用に出したログが、ログ収集基盤や外部の監視サービスに送られて漏れるケースがあります。Pythonの logging でマスキングする例です。

import logging
import re

class PIIMaskFilter(logging.Filter):
    PATTERNS = [
        (re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+"), "[EMAIL]"),
        (re.compile(r"0\d{1,4}-?\d{1,4}-?\d{3,4}"), "[TEL]"),
        (re.compile(r"(?i)bearer\s+[\w.-]+"), "Bearer [TOKEN]"),
    ]

    def filter(self, record):
        msg = record.getMessage()
        for pattern, repl in self.PATTERNS:
            msg = pattern.sub(repl, msg)
        record.msg, record.args = msg, ()
        return True

logger = logging.getLogger("app")
handler = logging.StreamHandler()
handler.addFilter(PIIMaskFilter())
logger.addHandler(handler)
logger.setLevel(logging.INFO)

logger.info("user=taro@example.com tel=090-1234-5678 auth=Bearer abc.def.ghi")
# => user=[EMAIL] tel=[TEL] auth=Bearer [TOKEN]

正規表現によるマスキングは"最後の砦"です。そもそも、リクエスト全体やユーザーオブジェクトを丸ごとログに出さない設計にすることが基本です。

5. ストレージを外部公開しない

検証のつもりで公開設定にしたストレージが、そのまま放置されるのは典型的な事故パターンです。AWSなら、アカウント全体でS3のパブリックアクセスをブロックしておけます。

aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

設定を確認するコマンドです。

aws s3control get-public-access-block --account-id 123456789012

6. 不要になった検証環境を削除する

「あとで消そう」と思った検証環境が、パッチも当たらないまま残り続けるのはよくある話です。

  • IaC(Terraformなど)で環境を作り、destroy で確実に消せるようにする
  • リソースに作成者・用途・削除予定日のタグを付ける
  • 定期的に棚卸しして、持ち主のいないリソースを削除する

7. 最小権限・短期間の認証情報を使う

漏れたときの被害を小さくするには、"権限を絞る"ことと"有効期限を短くする"ことが効きます。

  • IAMユーザーの長期アクセスキーより、IAMロール・一時認証情報を使う
  • CI/CDからクラウドへの認証は、OIDC連携で長期キーを持たない構成にする
  • 本番データへのアクセス権は、必要な人に必要な期間だけ付与する

8. 生成AIに機密情報・個人情報を入力しない

エラー調査のために、本番のログやデータをそのまま生成AIに貼り付けるのは危険です。入力データの扱い(学習への利用や保存期間)は、サービスや契約プランによって異なります。

  • 会社が許可したAIサービス・プランだけを使う
  • 貼り付ける前に、個人情報・認証情報・顧客名を置き換える
  • 社内ドキュメントをAIに読ませるRAGでは、"元データのアクセス権を検索結果にも反映する"

また、外部の文書やWebページをAIに読ませる仕組みでは、文書に仕込まれた指示でAIを操る「間接プロンプトインジェクション」によって、情報が持ち出されるリスクも指摘されています。AIに渡す権限は必要最小限にしておきましょう。

9. ブラウザに業務パスワードを保存しない

インフォスティーラー(情報窃取型マルウェア)は、ブラウザに保存されたパスワードやログイン中のセッション情報を盗みます。開発者の端末は、クラウドの管理画面やリポジトリへのアクセス権を持つため、特に狙われやすい存在です。

  • 業務アカウントは、会社が管理するパスワード管理ツールで扱う
  • 可能なところはパスキー(FIDO2)に切り替える
  • 出所の分からないツール・拡張機能をインストールしない

10. 依存ライブラリの脆弱性を継続的にチェックする

自分のコードに問題がなくても、利用しているライブラリの脆弱性から情報が漏れることがあります。

# Node.js
npm audit

# Python
pip install pip-audit
pip-audit

Dependabot などの自動更新ツールを有効にし、SBOM(ソフトウェア部品表)で「何を使っているか」を把握しておくと、新しい脆弱性が公表されたときに素早く影響を確認できます。

まとめ

やること 効果
認証情報を環境変数・シークレット管理へ コード経由の漏洩を防ぐ
gitleaks+プッシュ保護 うっかりコミットを仕組みで止める
漏れたら即ローテーション 被害を最小化する
ログのマスキング ログ基盤経由の漏洩を防ぐ
パブリックアクセスのブロック 設定ミスによる公開を防ぐ
最小権限・一時認証情報 漏れたときの被害を小さくする
生成AIの利用ルール シャドーAIによる漏洩を防ぐ
依存関係のスキャン ライブラリ経由のリスクを減らす

どれも一つひとつは地味な対策ですが、"仕組みとして組み込んでおけば、注意力に頼らずに済む"のがポイントです。まずはチェックリストのうち、すぐできるものから取り入れてみてください。

本記事で触れたシークレット管理、SAST、SBOM、プロンプトインジェクション、パスキー(FIDO2)などは、PD試験 科目Aのシラバスにも含まれるテーマです。

👉 科目A-1 入門学習(無料)
👉 PD試験 問題演習道場(無料・解説付き)

参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?