CI/CD パイプラインにおけるベストプラクティス

本番環境を保護する – IaC を使用することで、アカウントおよび環境のメンテナンスに必要なほぼすべてのことを実行できるため、コンソールやプログラムによるアクセスを制限することで本番環境を保護するために、あらゆる努力を行うことが重要です。アクセスを少数のユーザーに制限する (またはどのユーザーにも許可しない) ことをお勧めします。AWS CloudFormation を通じて IaC をデプロイする際にユーザーに必要なアクセス許可は限定的なものです。ほとんどのアクセス許可は、サービスロールを介して CloudFormation サービスに割り当てられます。詳細については、CloudFormation ドキュメントの「サービスロール」および「Implementing policies for least-privilege permissions for AWS CloudFormation」を参照してください。

環境ごとに個別のアカウントを作成する – 各環境に個別の専用アカウントを割り当てることで、デプロイプロセスを簡素化し、アカウントレベルできめ細かいアクセスコントロールを作成できます。複数の環境でリソースを共有すると、分離されたユニットとしての環境の整合性が低下します。環境を同期したうえで分離した状態で維持することが推奨されます。これは本番環境ではさらに重要です。なぜなら、そのアカウント内のすべてのものを本番リソースとして扱う必要があるためです。

個人を特定できる情報 (PII) を本番環境に制限する – セキュリティと責任リスクからの保護の両方の観点から、PII は可能な限り保護してください。可能な場合、下位環境では機密データである可能性のあるデータを本番環境からコピーせずに、匿名化されたデータまたはサンプルデータを使用してください。

リポジトリ内のコードを確認する – 完全な CI/CD プロセスでは、パイプラインのエントリポイントが 1 つに集約されるため、その 1 つのポイントを保護する必要があります。このため、機能ブランチをメインブランチにマージする前に、複数のコードレビューを要求することが推奨されます。これらのコードレビューは、資格のある任意のチームメンバーが実施できますが、少なくとも 1 人のシニアメンバーがレビューする必要があります。コードは、レビュアーによって厳密にテストされる必要があります。結局のところ、パイプラインの問題を修正する最善の方法は、パイプラインに問題を持ち込まないようにすることです。また、マージする前に、レビュアーからのすべてのコメントを解決することが重要です。この解決は、変更が不要である理由の説明にすぎない場合もありますが、すべてのコメントに対処することは、問題がパイプラインに持ち込まれるのを防止するのに役立つ重要な追加チェックです。

頻繁に小規模なマージを行う – 継続的インテグレーションを最大限に活用するためには、ローカルの変更も継続的にパイプラインにプッシュすることが推奨されます。結局のところ、ローカル環境も開発環境に追随していれば、開発環境が同期した状態を維持することがはるかに有益になります。