午前2時のアラームと500GBのデータ脆弱性
午前2時、OpsGenieからの通知でスマホが激しく振動しました。セキュリティ監査チームが、S3上の500GBのバックアップデータが「生（raw）」の状態、つまり一切暗号化されていないことを発見したのです。IAMユーザーが一人でも漏洩すれば、2020年から現在までの全顧客情報が即座に流出してしまいます。寝ぼけ眼の中で真っ先に思い浮かんだのが、この脆弱性を塞ぐためのツール、GnuPG（GPG）でした。これは1999年からLinuxの世界を守り続けているオープンソースの暗号化標準です。
機密性の高い .env ファイルや秘密のソースコードを扱っていたり、Slack経由でファイルを送る際に覗き見を心配したりしているなら、GPGを避けて通ることはできません。以下にまとめる内容は、私が本番環境でのトラブル対応を通じて得た知見です。
クイックスタート：5分でできるファイル暗号化
理論は後回しにして、まずは動かしてみましょう。これは、機密ファイルを送信する前に私がよく使っている3ステップのクイック手順です。
1. キーペア（公開鍵と秘密鍵）の作成
ターミナルに以下のコマンドを入力して開始します：
gpg --full-generate-key「RSA and RSA」を選択してください。キーの長さについては、現代のブルートフォース攻撃に対する安全性を確保するため、2048ビットではなく常に4096ビットを優先することをお勧めします。
ヒント：パスフレーズ（Passphrase）は最後の砦です。toolcraft.appなどを利用して、32文字のランダムな文字列を生成しましょう。暗号化の努力を無駄にしたきたくなければ、誕生日やペットの名前などは使わないでください。
2. 高速ファイル暗号化
作成した公開鍵を使用して、config_prod.yamlファイルを暗号化する例です：
gpg --encrypt --recipient "[email protected]" config_prod.yaml実行すると config_prod.yaml.gpg というファイルが生成されます。これで、元のファイルを削除したり、クラウドストレージにアップロードしたりしても、盗み見られる心配はありません。
3. 必要な時の復号
元の内容を取り出すには、以下のコマンドを実行します：
gpg --decrypt config_prod.yaml.gpg > config_prod.yaml公開鍵暗号（非対称暗号）：正しく使うための基本理解
よく「zip -eの方が手っ取り早いのに、なぜGPGで複雑にするのか？」と聞かれます。その答えは「パスワード管理」にあります。共通鍵暗号（zipやopensslなど）では、送信者と受信者が同じパスワードを共有する必要があります。そのパスワードをチャットやメールで送ること自体が致命的な弱点となります。
GPGはこの問題を公開鍵暗号（Public Key Cryptography）の仕組みで解決します：
- 公開鍵（Public Key）： 投函口はあるが取り出し口がない郵便ポストのようなものです。GitHubで公開したり、誰に送っても大丈夫です。
- 秘密鍵（Private Key）： そのポストを開けるための唯一の鍵です。自分のコンピュータ内に厳重に保管する必要があります。
日々の業務では、まず公開鍵をパートナーに送ります。相手はそれを使ってデータを暗号化し、こちらに送り返します。たとえハッカーが途中でファイルを奪ったとしても, 私の秘密鍵がなければ、ただの無意味な文字列の羅列にしか見えません。
キー管理：システム管理者が覚えておくべき必須コマンド
GPGを使いながらキー管理の方法を知らないと、PCの買い替えやシステムのスケール時にトラブルに見舞われることになります。
既存キーリストの確認
システム内に誰のキーがあるかを確認するには、以下を使います：
gpg --list-keys # 公開鍵をリスト表示
gpg --list-secret-keys # 自分の秘密鍵をリスト表示キーのバックアップ（エクスポート）
秘密鍵を紛失することは、暗号化されたデータへのアクセス権を永久に失うことを意味します。そんな事態は避けなければなりません。キーをエクスポートして、USBメモリや安全な保管庫（Vault）に保存しておきましょう：
# 共有用に公開鍵をエクスポート
gpg --armor --export "[email protected]" > my_pub.asc
# バックアップ用に秘密鍵をエクスポート（取り扱い注意！）
gpg --armor --export-secret-keys "[email protected]" > my_priv.asc--armor フラグはバイナリ形式をASCIIテキストに変換します。これにより、保存やコピー＆ペーストが容易になります。
本番環境へのデプロイ：自動化と実戦で得た教訓
サーバー上でGPGを扱うには、スクリプトが実行されるたびに手動でパスワードを入力するわけにはいかないため、工夫が必要です。
1. 非対面モード（–batch）
自動バックアップなどのcronジョブでは、GPGがユーザー入力を待って停止しないよう、--batchフラグを使用します：
echo "あなたのパスフレーズ" | gpg --batch --yes --passphrase-fd 0 --decrypt backup.gpg2. 失効証明書（Revocation Certificate）
キーを作成したら、すぐに失効証明書も作成しておきましょう。万が一PCが盗まれた場合、このファイルを使って古いキーが安全でないことを通知できます：
gpg --gen-revoke "[email protected]" > revoke.asc3. キーの信頼レベル（Trust Level)
GPGの基準は厳格です。同僚のキーをインポートした際、「キーが信頼されていません」というエラーが出ることがあります。その場合は gpg --edit-key コマンドを使い、trust と入力して、レベル4または5を選択して相手を信頼することを確定させます。
おわりに
GPGは噂されているほど難しくはありません。最も難しいのは、クラウドにデータを上げる前に「すべてを暗号化する」という習慣を身につけることです。あの午前2時の事件以来、私はすべてのCI/CDパイプラインにGPGを組み込み、ログやデータベースを自動的に保護するようにしました。今ではぐっすり眠れています。
サーバーのセキュリティを強化しているなら、GPGとLUKS（ディスク暗号化）の併用を検討してみてください. セキュリティは何層にも重なる旅のようなものであり、GPGはその中でもあなたのデータを守る最も強固な盾となるはずです。
