こんにちは！インシデントレスポンスやデジタルフォレンジックの世界へようこそ。
SOC（セキュリティオペレーションセンター）で日々、サイバー攻撃の痕跡を追いかけているアナリストの私から、今回はシステムを守るための非常に大切なテーマをお届けします。
セキュリティの現場でよく言われる言葉に、「ログは嘘をつかない」というものがあります。しかし、実はこれ、「攻撃者に改ざんされていなければ」という大きな条件付きなんです。
今回は、新人のIT担当者や開発者の方向けに、ログがなぜ狙われるのか、そしてどうやって鉄壁の守りを作るのかを、身近な防犯にたとえながら優しく紐解いていきたいと思います。一歩ずつ、しっかりと対策を学んでいきましょう！
—
1. なぜ攻撃者は「ログ」を消したり書き換えたりするのか？
皆さんは、自宅の玄関に防犯カメラを設置していると想像してみてください。もし泥棒に入られたとき、その防犯カメラの映像があれば、顔や侵入経路が一発でわかりますよね。警察もすぐに動けます。
サイバー攻撃者にとって、サーバーの「アクセスログ」や「エラーログ」は、まさにこの防犯カメラそのものです。
- 「どこから侵入したのか（IPアドレス）」
- 「何時何分にどんな不正なコマンドを実行したのか」
- 「どのファイルを盗み出したのか」
これらがすべて記録されているため、攻撃者は自分の足跡を消したくなります。つまり、システムに侵入したあとに最初に行う仕事が「ログの改ざんや削除」なのです。もしログが書き換えられていたら、私たちSOCアナリストは「いつの間にか侵入されていたけれど、何が起きたか全くわからない」という最悪の状況に陥ってしまいます。
だからこそ、ログそのものを「絶対に書き換えられない状態」にする必要があるのです。
—
2. ログを守る第一歩：「WORMストレージ」で日記帳をコンクリートで固める
ログを改ざんから守るための強力な武器の一つが WORM（Write Once, Read Many） という技術です。
イメージとしては、「一度だけ文字を書けるが、二度と消したり書き換えたりできないコンクリートの日記帳」を想像してください。どれだけ権力を持った管理者であっても、一度書き込まれたログを後からコソコソと消去することは物理的（あるいは論理的）に不可能になります。
クラウド環境（例えばAWSなど）でも、このWORMの考え方が使えます。Amazon S3の「オブジェクトロック（Object Lock）」機能を使えば、指定した期間は絶対にデータを削除できないようにロックをかけることができます。
実務で使える！AWS S3 バケットポリシーの設定例
開発やインフラの現場で、AWS S3に保存するログを保護するための設定例を見てみましょう。ここでは、一定期間（例では30日間）データの削除や上書きを禁止する設定を定義しています。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ProtectSystemLogsFromTampering",
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:DeleteObject",
"s3:DeleteObjectVersion",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::your-secure-audit-logs-bucket/*",
"Condition": {
"NumericLessThan": {
"s3:ObjectAgeDays": "30"
}
}
}
]
}この設定では、S3に保存されてから30日以内（s3:ObjectAgeDays が30未満）のオブジェクトに対しては、誰であっても（Principal: *）削除（s3:DeleteObject）ができないようにブロックしています。これで、たとえサーバーが乗っ取られて管理権限を奪われても、過去のログは守られます。
—
3. ログの「デジタル署名」で一文字の違いも見逃さない
「書き換えができないようにする」だけでなく、「もし途中でこっそり書き換えられたら気づけるようにする」仕組みも重要です。これが デジタル署名 や ハッシュ値（チェックサム） の活用です。
身近な例で言うと、高級な封印シールや、未開封であることを証明するシュリンクパックのようなものです。封印が破られていたり、中身が書き換えられていたりすると、一目で「あ、誰かが触ったな！」と分かりますよね。
システムでも同様に、ログファイルが生成された瞬間にその内容から一意の「ハッシュ値」を計算し、別の安全な場所に保管、または公開鍵暗号を使ったデジタル署名を付与します。
実務で使える！Linuxでのログの整合性チェック（SHA-256）
例えば、大切なログファイルを安全に出力・保管する際、次のようにコマンドを使ってハッシュ値を生成し、記録しておくことができます。
#!/bin/bash
# 対象のログファイル名
LOG_FILE="/var/log/secure_audit.log"
# 本日の日付を取得
TODAY=$(date +%Y%m%d)
# ログファイルのSHA-256ハッシュ値を計算して、改ざん防止用の別ファイルに保存する
# （このハッシュ保存先ファイルは、別の安全なサーバーへすぐに転送するのがコツです）
sha256sum ${LOG_FILE} > /var/log/checksums/secure_audit_${TODAY}.sha256
echo "ログファイルのハッシュ値を正常に記録しました。指紋の登録完了です！"もし攻撃者がログファイルを1文字でも書き換えると、sha256sum で計算される値が全く別のものに変貌します。定期的にこのハッシュ値を照らし合わせることで、不正な改ざんを瞬間に検知できるのです。
—
4. ログ転送の安全性：「TLS暗号化と相互認証」で途中の盗聴・改ざんを防ぐ
サーバーで生成されたログを、安全な分析用サーバー（SIEMなど）へ集約する際にも注意が必要です。ログを「ただの電波（平文）」で送ってしまうと、通信の途中で悪い人に内容を書き換えられたり、盗聴されたりしてしまいます。
これは、「大事な手紙を、鍵のかかっていない透明なカプセルに入れてポストに投函するようなもの」です。途中で誰かに中身を書き換えられてしまう危険がありますよね。
そのため、ログの転送経路は必ず TLS（Transport Layer Security） で暗号化し、さらに相互認証（mTLS: Mutual TLS）を組み合わせるのがプロの現場の鉄則です。
実務で使える！Rsyslogを用いたTLS暗号化転送の設定例
Linuxの標準的なログ転送ツールである rsyslog を使って、安全にログを暗号化転送する際の設定例（クライアント側）を見てみましょう。
# rsyslogでTLS暗号化と証明書検証を行うための設定スニペット
# 1. ネットワークドライバとしてGnuTLSまたはOpenSSLを指定
$DefaultNetstreamDriver gtls
# 2. 証明書の信頼関係（CA証明書）の場所を指定
$GlobalNetstreamDriverCAFile /etc/rsyslog.d/certs/ca.pem
# 3. クライアント自身の証明書と秘密鍵を指定（相互認証用）
$GlobalNetstreamDriverCertFile /etc/rsyslog.d/certs/client-cert.pem
$GlobalNetstreamDriverKeyFile /etc/rsyslog.d/certs/client-key.pem
# 4. 通信のモードを「認証付き暗号化（モード3）」に設定
$GlobalNetstreamDriverAuthMode x509/name
$GlobalNetstreamDriverPermittedPeer logserver.example.com
# 5. 転送先の指定（TCPのポート10514を使い、暗号化ストリームを適用）
*.* @@logserver.example.com:10514;RSYSLOG_SyslogProtocol23Formatこのように、通信の最初でお互いの身分証（証明書）を確認し合い（相互認証）、やり取りする内容をすべて暗号化（TLS）することで、ネットワークの途中で悪い人にログを覗かれたり、すり替えられたりするリスクを完全にシャットアウトします。
—
まとめ：一歩ずつ、強固な防犯の仕組みを作ろう
今回は、ログの完全性と改ざん防止対策について、インシデントレスポンスの現場目線でお話ししました。
- WORMストレージで、ログという「日記帳」をコンクリートで固める。
- ハッシュ値やデジタル署名で、指紋のように一文字の改も逃さず検知する。
- TLS暗号化と相互認証で、転送中の手紙を頑丈なカプセルに入れて守る。
セキュリティ対策というと難しく聞こえますが、要は「身の回りの大切なものを泥棒から守る防犯の工夫」と同じです。一度にすべてを完璧にするのは大変ですので、まずは「重要なログを別の安全な場所にコピーする」「転送を暗号化する」といったところから、一歩ずつ進めていきましょう！
あなたの書いたコードや築いたインフラが、サイバー攻撃に負けない強靭なシステムになることを、SOCアナリストとして心から応援しています。
コメント