カスタマーサクセス部の井出です。
AWS Summit Japan 2024 にてセッション「安全とスピードを両立するために ~ DevSecOps とプラットフォームエンジニアリング~(AWS-09)」に参加したため、重要と思った箇所のまとめを記載します。
オンデマンド配信:
https://japansummit.awslivestream.com/aws-09/live/japansummit.awslivestream.com
※こちらのリンクは2024年7月5日以降クローズされています。
資料: https://pages.awscloud.com/rs/112-TZM-766/images/AWS-09_Builder-Experience_AWS_Summit_JP_2024.pdf
参加目的
参加目的としては、最近DevSecOpsに興味があり、開発サイクルの全体像やどのようにSec部分を導入するかを学ぶことです。
セッション概要
ご登壇: アマゾン ウェブ サービス ジャパン合同会社 金森 政雄氏
内容
安全とスピードが求められる理由
デプロイ頻度が高い・変更のリードタイムが短いほど変更の失敗率は下がる。
デプロイ頻度が低い・変更のリードタイムが長いほど変更の失敗率が上がる。
→ スピードと品質は比例する
アジリティのための分割
- モノリスの開発の課題
- 変更が競合したり、別の開発に影響を与える可能性
→ 調整の負担が増える - デリバリーパイプラインが1本しかなく変更が滞留してしまう
→ 開発スピードが落ちる
- 変更が競合したり、別の開発に影響を与える可能性
- マイクロサービスの開発のメリット
- 変更の競合、別の開発への影響が小さくなる
- 同時並行で複数のデリバリーが可能になる
自動化
マイクロサービスの開発となることで、計画・開発~運用までを一つのチームで担うことになる
→ 自動化することがポイントになる
DevSecOps
ShiftLeftの考え方
- セキュリティへの取り組みを開発サイクルの早い段階に移すこと
→ 早い段階に移すとは、テストやリリースの段階でセキュリティチェックをするのではなく、設計やビルドの段階から考慮するということ
→ セキュリティの問題を放置放置することなく、迅速なデリバリーが可能になる
開発の各段階で導入できるセキュリティ対応
ローカル開発
- IDEプラグイン
- Pre-Commitフック
- コードレビュー
Build
- 静的解析(SAST)
- ソフトウェア構成解析(SCA)
- ライセンスチェック
Test
- 動的解析(DAST)
パイプライン自体のセキュリティ
ソフトウェアサプライチェーンにも脅威が潜んでいる
例えば
- 不正な(権限のない)コード変更
- ビルド実行環境
対策例
- SLSA(Supply chain Levels for Software Artifacts)を使用したソフトウェアサプライチェーンの評価
プラットフォームエンジニアリングと運⽤モデル
こちらは割愛します。
実際にチームで開発を進める際の方法をご説明されていました。
印象に残ったこと
- パイプラインに組み込まず、個人ですぐに対応できるものがあること(IDEプラグインやPre-Commitフック)
→ 導入が容易なので導入がしやすいため、チームで標準として取り入れてセキュリティ対策の一歩としても良いのではないかと思いました。 - パイプライン自体のセキュリティ
→ DevSecOpsと聞くとソフトウェアチェックの視点のみになりがちでしたが、パイプライン自体のセキュリティにも目を向ける必要があると改めて認識しました。 - AWSでできるハンズオン・検証方法があること
→ 「Security for Developers ワークショップ」や「SLSAの検証」の紹介がセッション内でありました。実際にやってみて今後ブログにしようかなと思います。
まとめ
最後までご覧いただきありがとうございました。
本セッションで出てきた「Deployment Pipeline Reference Architecture」は一度目を通すと理解が深まると思います。 pipelines.devops.aws.dev
以降に記載のリンクは2024年7月5日以降クローズされています。
個人としては今CDKを使用しているため、下記のセッションもオンデマンドで見てみようと思います。
https://japansummit.awslivestream.com/aws-33/live/japansummit.awslivestream.com
他のセッションについても2024年7月5日までオンデマンドで配信や資料公開もされています。
興味のある方はこちらよりご視聴ください。