AWS CodePipeline でステージレベルの手動および自動のロールバックをサポート
AWS CodePipeline V2 タイプのパイプラインでステージレベルのロールバックのサポートが開始されたので、本番環境に確実に変更をデプロイできるようになりました。あるステージで何らかのアクションが失敗したためにパイプライン実行が失敗した場合、そのステージで以前に成功したパイプライン実行にロールバックすることで、そのステージをすぐに既知の良好な状態に戻すことができます。ソースステージを除き、成功か失敗かにかかわらず、どのステージでも変更をロールバックできます。 コンソール、API、CLI、または SDK から手動でステージのロールバックを開始することも、失敗したら自動的にロールバックを選択するようにパイプライン定義内でステージを設定することもできます。ロールバックが開始すると、新しいパイプライン実行がそのステージから開始し、選択したパイプライン実行からの変更が適用されるか (手動ロ
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
