Google Cloudには、kmsという秘密鍵を用いた暗号化・復号を煩雑にすることなく行うことができるマネージドサービスがあります。
職掌分散を保ちながらセキュリティを担保することができます。
また、鍵の更新スパンを設定することにより、古いファイルの秘密鍵を保存したまま、新しい秘密鍵へと随時更新することができます。古い鍵は明示的に破棄されない限り有効状態であり、gcloud kmsコマンドを用いて、暗号化する場合は、自動で最新の鍵を使用して暗号化し、復号の際は自動で暗号化時の鍵を使用して、データを復号します。
ただし、鍵の寿命を小さくすることで、不正ファイルアクセスに対する安全性を高めることができることから、本当に厳重な保管が必要とされる重要なファイルに関しては鍵は更新のタイミングでファイルを復号し、常に最新の秘密鍵で再暗号化をかけるのが良いです。この手順は、各言語のAPIやgcloudコマンドを利用して自動化することができます。
keyringはnamespace、keyNameはkeyring内での鍵の識別子の働きをします。keyring,keyNameおよびkeyのバージョンによってkmsは、秘密鍵を一意に保存しています。gcloud kmsコマンドでは、versionにおいては、暗号化においては明示的に指定がない場合は自動で最新版が、復号においては、自動的に暗号化した時の公開鍵（対称暗号の場合）に対応する秘密鍵を選出して復号してくれます。
gcloud kms encrypt --location global --keyring $keyringName --key $keyName --plaintext-file sample.txt --ciphertext-file sample.txt.enc
gcloud kms decrypt --location global --keyring $keyringName --key $keyName --plaintext-file sample.txt --ciphertext-file sample.txt.enc
これら暗号化したファイルは特定のgoogleアカウントのみでgcsログインできるようにしたGCSなどで保管しておくことで、普通のファイル共有を行うよりも強固にファイル共有ができるほか、ファイルが設定の誤りなどで流出してしまっても、管理者アカウントで鍵を無効にすることで暗号の強度と同じ難易度まで解読を困難にしファイルを守ることができるようになります。
また、この際、鍵を管理するアカウント、鍵を使うアカウントやプロジェクトを別々に用意することで、サービス運用に関わる操作と鍵の管理は別権限にすることで、鍵自体の一元管理や、必要以上にプロジェクトの鍵作成の管理者が増えて、漏洩するリスクが高まることや、どちらかのアカウント情報が漏洩してプロジェクトにログインされてしまった場合でも、鍵の漏洩だけではgcloudコマンドの復号権限がない。Storageのアカウント情報だけでは、鍵を取得できないので、復号ができないというような状態を作り出すことができ、ワークフローさえ整えてしまばより強固かつ、管理が容易なセキュリティマネジメントができるようになります（職掌分散）。
僕らの開発チームではこれらの技術によって本当に漏洩してはいけないファイルは確実に機密を保護できる状態になることを義務付けています。
これらの操作は自前でopensslの安全性を担保しながら同じような仕組みを運用するのに比べ、非常に楽に実現ができます。なかなか地味なサービスですが、非常に有用なので、SLAでシビアな情報管理が求められるような開発では、ぜひ、ベストプラクティスを探ってみるといいと思います。
今年は担当分全記事乗り切った...！！！