SQS(Simple Queue Service)とは Amazon Simple Queue Service (Amazon SQS)は、AWSの完全マネージド型のメッセージキューイングサービスです。完全マネージドのため、ミドルウェアの管理や運用をユーザ側が行わなくてよく、AWS側に任せることができます。 AWSが提唱しているSQSのメリットです。 管理オーバーヘッドの排除 完全マネージド型のサービスのため、SQSを使用するにあたってのメッセージングソフトウェアの管理や、設定、インフラ基盤の運用などを考えなくてよく管理コストが下がります。 確実にメッセージを配信 SQSに転送されたメッセージは、複数のアベイラビリティーゾーンで冗長化されて保存されているため、必要な時にはいつでも使用することができます。 暗号化により機密データを安全に保つ SQSでは、サーバーサイド暗号化(SSE)とKMS

SNSからメッセージをAWSの別アカウントSQSに送ってKMSで暗号化する設定をしたのでやり方を紹介します。 どういうことか分かりやすく図で書くと、以下のようになります。 AWSアカウントA(111111111111)のSNS(simple-sns)から、AWSアカウントB(222222222222)のSQS(simple-sqs)に対してメッセージを送ってKMS(simple-kms)でメッセージを暗号化してSQSで保持するようにします。 Account AのSNSからAccount BのSQSにメッセージを送る 手順 1. SNSトピックを作成 @AWSアカウントA 2. KMSを作成 @AWSアカウントB 3. SQSキューを作成 @AWSアカウントB 4. SQS側でSNSをサブスクライブするように設定 @AWSアカウントB 5. SNSからメッセージの送信テスト @AWSアカウン

はじめに KMSの権限管理、およびKMSとSQSの権限の関係がややこしかったので整理のために書きます。 主に自分の整理のために書きます。誰かのためにもなると良いなと思います。 なお、私はバックエンドを専門としています。普段terraformをゴリゴリ書いてたりはするのですが、まだ半人前なので内容についての責任は持てませんのでご容赦ください。 とはいえ、AWSのドキュメントを整理しているだけなので誤りはないかとは思いますが。 KMS KMSのドキュメントから引用しつつ、整理します。 Key policies are the primary way to control access to KMS keys. Every KMS key must have exactly one key policy. KMSの鍵は主にキーポリシー側で制御することが望まれ、常に1つの鍵が紐づきます。 これはA

CSRF 対策は One Time Token を form なりに付与して、サーバ側でチェックすれば良い。 それをデフォルトでサポートしてるフレームワークなどもあるし、なくてもライブラリでいくらでも対応できる。 どうせ完全にステートレスなサービスはなかなかないので、サーバ側に redis や memcache を用意するのも別に大変じゃない。 なので、 CSRF 対策として Token を付与するのは、最も安全で推奨できる方式ではある。 っていうのを踏まえた上で、もう SameSite=Lax デフォルトだけど、今でも Token 必須なの？みたいなのがたびたび話に出るので、いい加減まとめる。 前提 この話は、スコープがどこなのかによって話が多少変わるので、そこを絞る。 今回は Passive ではなく Active に対策していく場合を考えるので、前提をこうする。 SameSite=l

江口大和さん（元弁護士）が横浜地検特別刑事部から犯人隠避教唆の疑いをかけられ、逮捕されたのが平成30年10月15日。 彼はそれまでの任意の検事取調べにおいて被疑事実を否認していた。 そして、逮捕直後の弁解録取において彼は黙秘権の行使を宣言した。 日本国憲法第38条1項 何人も、自己に不利益な供述を強要されない。 ところがそこから約21日間、合計約56時間、一言も話さない江口さんに対して、横浜地検特別刑事部の検察官（そのうちのほとんどは川村政史検事）は取調べと称して「僕ちゃん」、「お子ちゃま」、「ガキ」呼ばわりし、「うっとうしい」、「どうやったらこんな弁護士ができあがるんだ」、「嘘を付きやすい体質」、「詐欺師的な類型の人に片足突っ込んでる」などと言ったり、江口さんの弁護人の活動を侮辱したりする発言をし続けた。 それでも江口さんは決して口を開くことはなく、耐え抜いた。 このような検察官の取調べ

いわさです。 Amazon SQSではキューとの通信時はデフォルトで暗号化されていますが、保管時の暗号化はオプションです。 この度、AWS Key Management Service(KMS)ではなくSQSが管理する暗号化キーを使う、SSE-SQSが利用出来るようになりました。 従来はサーバーサイド暗号化(SSE)としてAWS Key Management Service(KMS)を使った暗号化のみを選択することが出来ていました。 SSE-SQSを使うとKMSを利用しないため、従来のKMS利用に伴う追加料金が不要になります。 また、鍵の管理も不要になります。 従来はデフォルトキー（SQSマネージドCMK）の場合はキューをクロスアカウントで利用する際に不都合があり個別のCMK管理が必要でしたが、SSE-SQSの場合だともう少しライトに、暗号化しつつアクセスポリシーのみで制御が可能です。 設

私個人の障害対応の経験と 一昨日参加したIncident Response Meetup vol.1での学びから 障害対応において大切だと感じていることをまとめる。 障害とは リリース後のシステムにおいてシステムの不具合やユーザーの操作ミスによってユーザー業務に影響が出ているもしくは出る恐れがあるもの。 障害対応の目的 システムを直すことではなく、ユーザー影響の回避・低減・早期回復をすること。 障害対応に対する心構え システムの信頼性の要である 障害への対応の仕方でユーザー影響が大きく変わる いつ発生するかわからないため特定の人が常に障害対応をするということは不可能である 素早く適切に行動するための備えが重要である 役割分担 障害対応では復旧対応、原因調査、ユーザーへの説明、社内調整などたくさんのことをやる必要がある。 またそれぞれの作業の難易度が高いことも多い。 一人の人間にできることは

GitHub、パブリックリポジトリのユーザーに4vCPU/16GBメモリ/150GBストレージのホステッドランナーを無償提供、従来よりも2倍のスペックに強化 GitHubは、コードのビルドやテスト環境などで使えるホステッドランナーを、パブリックリポジトリで開発をしているオープンソースの開発者向けに無償で提供しています。 今回、その無償のホステッドランナーが2倍のスペックに強化されたことが発表されました。 GitHub Hosted Runners for public repositories are now DOUBLE the size! Run your CI/CD Actions workflows with a 20% performance boost today. https://t.co/S9Dy9tHVB3 — GitHub (@github) January 17, 2

質問されることが多いのでPostgreSQL初学者が運用を行うためにしっておく知識に必要な内容をまとめる。 PostgreSQLの基本的なアーキテクチャ PostgreSQLのアーキテクチャを知らないと自分がやっている作業が危険な作業かどうかわからないし、パラメータの意味もわからない。 そこで以下のリンクを読むと良い。 富士通が後述の資料を参考にまとめたのだろうなと思われる記事。 非常によくまとまっているのでわかりやすい。 www.fujitsu.com もっと細かく知りたいならPostgreSQL Internalsがおすすめ。 富士通の資料と重複するところがあるがこっちが本家。 Githubで管理されているので誤字脱字などあったら気軽にPRを出してほしい。 www.postgresqlinternals.org PostgreSQL Internalsが少し古いので最新事情で知りたい場