[アップデート]GuardDutyが盗まれたEC2のクレデンシャルが別AWSアカウントで利用されたことを検知できるようになったので実際に試してついでにDetectiveで調査してみた GuardDutyがEC2から搾取されたクレデンシャルを別AWSアカウントで利用しても検知してくれるようになりました。実際にインシデントが発生した場合の対処方法も合わせて解説しています。 こんにちは、臼田です。 みなさん、GuardDuty使ってますか？(挨拶 今日は素晴らしいアップデートが来ました。EC2から搾取されたクレデンシャルが別AWSアカウントで利用されたときにAmazon GuardDutyで検知することが出来るようになりました！ Amazon GuardDuty now detects EC2 instance credentials used from another AWS account

Kaz 🇺🇸シアトル @kaz_kazuhisa 先日、妻が歯内治療を受けた時、その場で＄241支払った。そして今日、保険会社から＄137の請求書が来た。ここで＄137を追加で支払ってはいけない。この請求書の本当の意味は、＄137でいいのに病院で＄241支払ったという事。＄104の返金を請求しないといけない案件。これはアメリカ医療システムの罠。 Kaz 🇺🇸シアトル @kaz_kazuhisa ちなみに保険適用前の請求額は＄2,007 。保険ネットワーク割引が＄779、保険会社による支払いが＄1,090で、自己負担が＄137 でした。その場で＄241取られる理由もよくわからんし、ネットワーク割引っていうのもよくわからん。5年住んでるけど、アメリカの医療システムは未だに謎だらけ。 Kaz 🇺🇸シアトル @kaz_kazuhisa 周りの人の話を聞く限り、私の会社で入っている保険は

前提 Cloudflare Workers は知っていたが最近触って、本番環境へ導入済み。 普段は Erlang/OTP を書いてるので JavaScript は専門外 自社サービスの本番環境には Cloudflare Workers を導入済み OpenResty はエンタープライズ大規模環境向けで設計/開発経験あり 雑感 Cloudflare Workers® ざーっと見た感じ Nginx + Lua (OpenResty) のマネージド、さらに Edge で動かしてくれて、スケールも勝手にしてくれるバージョンという認識。実際 shared.dict / redis の代わりが Workers KV が利用できる。 さらにローカル開発環境が充実している、デプロイ後のログ確認も管理画面から簡単に利用できる。 Lua Introducing Cloudflare Workers これを読む

自分に正直になる習慣 フランスの哲学者アランは名言を遺している。 「幸福だから笑うのではない。笑うから幸福なのだ」 そのとおりだと思う。アクションから本質が生まれる。本質はあくまでも事後的に発生するものであって、本質という抽象はそれ単独で先行的に存在するものではない。 ぼくは中学生時代、プログラミングに夢中になった。よくわからないまま手さぐりでパソコンを使っているうちに、多彩な処理システムを構築できるプログラミングの魅力にどんどんのめり込んでいった。それがやがてビジネスにつながり、ぼくはそのビジネスでさらに成功を収めるべく野心をたぎらせていった。 要するに今日にいたるぼくのキャリアは、プログラミングとの出合いがすべてだ。プログラミングに出合わなければ、それはそれでまたまったく別のキャリアを描いていただろう。 あらかじめ目指すキャリアがあって、プログラミングに足を踏み入れたわけではないのだ。

自分に正直になる習慣 フランスの哲学者アランは名言を遺している。 「幸福だから笑うのではない。笑うから幸福なのだ」 そのとおりだと思う。アクションから本質が生まれる。本質はあくまでも事後的に発生するものであって、本質という抽象はそれ単独で先行的に存在するものではない。 ぼくは中学生時代、プログラミングに夢中になった。よくわからないまま手さぐりでパソコンを使っているうちに、多彩な処理システムを構築できるプログラミングの魅力にどんどんのめり込んでいった。それがやがてビジネスにつながり、ぼくはそのビジネスでさらに成功を収めるべく野心をたぎらせていった。 要するに今日にいたるぼくのキャリアは、プログラミングとの出合いがすべてだ。プログラミングに出合わなければ、それはそれでまたまったく別のキャリアを描いていただろう。 あらかじめ目指すキャリアがあって、プログラミングに足を踏み入れたわけではないのだ。

ritou です。 前の記事でちょっと確認済みメアドについての記載をしたあと、Twitterでちょっとやりとりしたり個別にDMで質問が来たりしたのでまとめます。 まとめ "確認済みメアド" のユースケースはいくつかある 新規登録時に自サービスで確認処理を行わずに利用 未登録ユーザーがソーシャルログインしてきた時に既存ユーザーとの紐付け IdPからもらった確認済みメアドをそのまま使っていい場合とそうじゃない場合がある 自サービスで提供しているメールアドレスかどうかで変わる部分を許容するかどうか email_provided のようなclaim があると便利かもしれない 確認済みメアドのユースケース 新規登録時の確認処理をスキップ これはID連携、ソーシャルログインのメリットとしてずっと言われているものです。 IdPで確認済みなのでRPは確認せずに信用して使おう というお話です。 よく知られて