KotlinとSpring Security 6.xを使って、Introspection Endpointでトークンを検証するOAuth2のリソースサーバ−を実装する AWS事業本部サービス部の佐藤です。 この前までTypeScriptばっかり触っていたのに、気づけばJavaとSpring Bootばかり触っていますね… KotlinとSpring Security 6.xを使ってOAuth2のリソースサーバーを試す機会がありましたので、手順を残そうと思います。2023年3月時点ではSpring Boot 3.xを使っているためSpring Security 6.xを使うことになるのですが、あまりネット上に情報が少なかったのとハマった部分も多かったので記事にしました。現在のSpring Security書き方をするように意識し、非推奨の書き方はしないようにしています。 新しいSpring

DevelopersIO Sapporo 2022 が開催され、久々のオフラインイベントが有りました。 その中でここ最近ライフワークのようになっていた、Spring, Tomcat 等の脆弱性対応について話してきました。 時間に対して資料がオーバーしていたため、共有できなかったURLをいくつか追記します。またコードについての解説も全くしていなかったのでそこもリンクを追記します。 時間がなかった参照リンク Log4j2 脆弱性問題における SpringBoot アプリケーションの検証 cve-2022-22965 Spring4Shell の影響調査 Tomcat の修正 Commit を読んで理解する CVE-2021-43980 piyolog - Log4jの深刻な脆弱性CVE-2021-44228についてまとめてみた JVNVU#94675398 Spring Frameworkにお

目次 目次 はじめに（本記事の見どころなど） テストについて話し合わなくてはならない テストの目的 「うまくいかないかもしれないものは何ですか？」 なぜテストをするのですか？ この場合に限り…… テスト駆動開発 〜テストについて語る前に説明が必要です〜 テストについて話しましょう なぜすべてのテストを自動化しないの？ テストカバレッジは有用な指標ですか？ 「テストをシフトレフトする」とはどういう意味ですか？ いつ、どこでテストすべきですか？ 十分なテストとはどれくらいですか？ おわりに はじめに（本記事の見どころなど） 今回は著者本人の許可をもらった上で、「テストについて話し合わなくてはならない」（原題は「We need to talk about testing」）を翻訳したので紹介します。 dannorth.net 本記事はDaniel Terhorst-North(Dan North

はじめに こんにちは。小室＠さっぽろです。2022/09/30 Tomcat で新しい脆弱性が JVN のサイトにて公開されました。 JVNVU#98868043 - Apache TomcatにHttp11Processorインスタンスにおける競合状態による情報漏えいの脆弱性 複数のクライアントから接続された場合、Http11Processorのインスタンスを共有していることに起因して、レスポンスのすべてまたはその一部を誤ったクライアントに送信するため、情報が漏えいする可能性があります。 という内容でなかなかな内容です。 気になる脆弱性であったため 趣味で コードを見てみました。Tomcat のコードを追うのは初めてなので理解が間違っているかもしれません。 理解が間違っているところや曖昧な箇所があれば指摘ください。 *1 「なぜそうなるのか」まではある程度調べたものの、再現方法に関しては

はじめに prismatix 事業部で QA エンジニアをしている長友です。 今回は私の所属するチームの方がテスト改善を行ってくださったので、そのお話です。 経緯 今私のいるチームには、私以外に K さんというメンバーの方がおられます。 これまで私の所属する prismatix 事業部で、いろいろなマイクロサービスの開発に携われてきた方です。エンジニアリング力が高く、テストに関する本も出されている方で、私もその方の本を持っています。ですから話すときはよくテストの話題になります。 その方が、これまで開発チームにいた中で作っていたテストコードによるテストのやり方に課題を感じていたということで、今回その改善をすることになりました。 いろいろ試行錯誤をされて、こうしたらいいのではないかというアイデアが出てきたので、それをどうやって開発チームに実践してもらうかをやってみたことをお話します。 なお、私

はじめに こむろです。 Spring4Shell についてです。どうせお前ら調査してたんだろ？と思ったあなた、大正解です。 結論 非常に広範な影響がありましたが、現時点で、Spring Framework 本体への修正パッチがすでに適用されています。そのためこれに準じたアップデートを実施することで脆弱性を回避できます。 spring-boot-2-6-6 spring-boot-2-5-12 spring-framework-5.3.18 Tomcat 9.0.62 またこれらのアップデートができない場合、以下の対応を取ることもできます。 不要なパラメータのマッピングを行わないようにコードを追加する （Binding のブラックリストへ class.* 系を追加） Java8 へ一旦ダウングレードする Tomcat 9.0.62 へ Update することで設定値自体の書き換えをできないよ

この記事はアノテーション株式会社 AWS Technical Support Advent Calendar 2021のカレンダー | Advent Calendar 2021 - Qiita 24日目の記事です。 はじめに Amazon VPC ドキュメントのよくある質問1にこんな内容があります。 Q:2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスが AWS のサービスのパブリックエンドポイントと通信する場合、トラフィックはインターネットを経由しますか? いいえ。パブリックアドレススペースを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除

先日騒ぎになっていた CVE-2021-44228 についてのアプリケーション側の対応について記載いたします。 緩和策としてすでに AWS WAF での Rule の Update 等が行われているため、AWS サービスの詳細については別途記事を御覧ください。 Log4jの脆弱性対策としてAWS WAFのマネージドルールに「Log4JRCE」が追加されました ここでは SpringBoot をベースとしたアプリケーションへの影響と対応可否の判断についてどのような調査を行ったかを記載します。 ひとまず結論 Spring 側から見解がすでに出ています。 Log4J2 Vulnerability and Spring Boot 以下抜粋します。 Spring Boot users are only affected by this vulnerability if they have switc

この記事は スターフェスティバル Advent Calendar 2021 の2日目の記事です。 qiita.com 昨日は @kajiken さんの スタフェスの 「エンジニアブログ」 はじめました でした。 zenn.dev 会社紹介含めて 開始 という感じのブログでしたね〜。 このブログ、Githubで書かれていて、ブログをレビューされたりしていて、面白い文化が見えた気がしました。 さて、本題 という事で、本題です。 私は 2021年の今年、 スターフェスティバル（通称： スタフェス）にJOINしました。 経緯はこの辺なんですが、選考はすべて リモートでしたし、実際にお会いした事ある人は カジュアル面談してもらったytakeさんとCTOの sotarok さんだけでした。 その他の方は誰も知らない、という状況の中、フルリモートで仕事をしていく状況での入社でした。 フルリモートによる在

AWS Fargate の Graviton2 対応が GA になりました。従来のコンピュートリソースより 20% 安く、最大 40% 高性能なリソースを利用できます。 https://aws.amazon.com/jp/about-aws/whats-new/2021/11/aws-fargate-amazon-ecs-aws-graviton2-processors/ 弊社が提供する Prismatix は Spring Boot 2 アプリケーションを AWS Fargate にデプロイして提供しています。 Prismatix を従来の Fargate から Graviton2 ベースの Fargate に移行するだけで AWS 利用費を下げることができ、AWS 利用費を下げることは顧客のサービス利用費を下げることになり、顧客の満足度向上にもつながります。 ぜひとも提供したい。早速

はじめに 随分間が空いてしまいました。 想定外の事象の原因についてとその回避策、そしてまとめ。これで最後です。 前回まで 3 回にわたって手法の検証、計画の作成、実施について記載しました。 AWSアカウント間のS3, DynamoDBデータ移行計画の記録 （背景と転送方法の検討） AWSアカウント間のS3, DynamoDBデータ移行計画の記録（データ完全性検証方法の検討） AWSアカウント間のDynamoDBデータ移行計画の記録（計画の実行と想定外の事象） 今回は、実施時に発生した事象についての原因の説明と回避について記載します。 発生した事象について おさらいになります。前回発生した事象から。 取り込みの Producer 及び転送用の Worker が想定以上に働いておらず、転送対象のテーブルの Write Capacity Unit が想定の 1/5 程度で頭打ちになってしまってい

はじめに こんにちは。事業開発部のこむろ＠さっぽろです。 最近、諸事情から所属部署でどこにでも顔を出す人として活動しています。 今回はJVMのメモリ周りについて初めて調べました。 背景 Javaアプリケーションを利用している場合、最近ではContainerを利用してアプリケーションを起動しているところも多いかと思います。わたしの所属する事業開発部では、ECSを利用して複数のJavaアプリケーション（Spring Boot）をContainerで稼働させています。 Containerで稼働させるため一つのホストのリソースをすべて割り当てられるわけではありません。Containerには利用できるリソースにハードリミットが設けられているため、リソースの配分には少々気を使う必要があります。 今まであまり意識してチューニング等していなかったのですが（富豪的にメモリを割り当てたりしてて深く考えていなか

最短でイッセンマンITエンジニアを目指すなら大炎上プロジェクトがオススメ！！経験浅でも採用の可能性が上がるし、週最大7日間1日15時間以上、プロに揉まれながらスキルを磨けるので面倒な家での積み上げは不要！やり遂げた際の経験値はヤバいし、活躍によってはPMが次のPJに引っ張ってくれるよ！— 代表取締役 岩元仁＠株式会社ロックシステム (@iwa3nen) 2021年8月28日 経験の浅いエンジニアが1千万の年収を得る最短ルートが、炎上案件に飛び込んですげぇ修行して界王拳をマスターしろなのか... 社員にそれを言えるのがすごいな。(いわもと様から社員向けではないとコメントを頂いたので、打ち消します) 炎上プロジェクトで心を病んだ人を多かれ少なかれ見てきて、人づてに色んな哀しみを聞いている身としては、危険としか言いようがない。 僕が若い頃にやった、月稼働400時間が2ヶ月続いたプロジェクトは炎上

はじめに prismatix事業部の中村です。 私が開発に携わっているEC/CRMのWebAPIプラットフォーム prismatix では検索サービスを提供しており、その内部では　Elasticsearch　を利用しています。 今回イチから　Elasticsearch　を勉強する機会がありましたので、構築方法や使い方を書いていこうと思います。 Elasticsearchとは Elastic社が提供している Elastic Stackというプロダクト群に含まれる、分散処理が可能検索及び分析エンジンです。 Elastic Stack には、下記のプロダクトが存在します。 Elasticsearch ： 心臓部となるJSONベースの検索/分析エンジン Kibana : 検索、可視化用のUI Beats ： アプリやインフラの統計情報等のデータ収集ツール Logstash ： データ収集パイプライ

何かを伝えたり聞いたりする時には本人と直接話す方がよい。当たり前っちゃ当たり前なのだが、意外とうまくできていないことも多いので最近特に強く意識するようにしている。 「どうなってるか分からなくてモヤモヤする」とか「あの発言や行動ってどういう意図なんだろう」とか、内に籠もって想像だけしているとロクなことがない。直接本人と話してみると実は何の問題もなかったなんてこともある。 ただ、直接話すのは簡単なようで難しい。話す側は感情のコントロールと言語化のスキルが要求される。聞く側のスタンスも重要で、これは話す側はコントロールできない領域なのでより難易度が上がる。話す側聞く側どちらかに負荷が偏ると相手のコミュニケーション能力のせいにして余計にめんどくさいことになってしまう。組織においては、直接話して物事を解決すること自体を推奨するといった工夫が必要かもしれない。また、ある程度はスキルトレーニングもあった

こむろ＠事業開発部です。 前回 の続きです。 そろそろ諸々の記憶が薄れ始めている頃なので早めに全部書ききっておきたいところです。 前回までのまとめ データの取得と転送方法についての検討は終わりました。 Amazon S3 の転送方法の検討と想定される時間の計測 → 完了 Amazon ElastiCache for Redis の転送方法の検討と想定される時間の計測 → 完了 Amazon DynamoDB の転送方法の検討と想定される時間の計測 → 完了 転送対象の絞り込み → 完了 重要データ、ログイン情報の3テーブルにフォーカスを絞る 認証情報は除外 データ完全性検証の方法検討 → 未着手 全体のスケジュール作成 → 未完成 転送作業の実施 → 未着手 今回のテーマ データ完全性検証の方法を検討します。 データ完全性検証について。ここでは、「移行元のデータ」と「移行先のデータ」が完全

はじめに 個人的に CloudNative なアプリケーションフレームワーク Quarkus のいろいろなモジュールを試しています。その中から今回は OpenID Connect クライアントモジュールを利用してみます。 QUARKUS - USING OPENID CONNECT TO PROTECT WEB APPLICATIONS USING AUTHORIZATION CODE FLOW 例では KeyCloak を利用していましたが、今回は Auth0 を利用しました。 事前準備 Quarkus ブランクプロジェクトの作成 Quarkus の最低限のブランクプロジェクトを作成します。追加の依存は何も指定しません。 Quarkus - Start coding with code.quarkus.io pom.xml の中は以下の通り。 <dependencies> <depend

はじめに おひさしぶりです。しがないOLくにきちです。久々のブログ投稿になりました。 最近はドキュメント整備を主な仕事にしてまして（たまにリファクタリングやテスト）新しくドキュメント環境作ってみたりドキュメント書いたりして過ごしてます。 その中で、これまでドキュメント作成に使用していた GitBook CLI の開発が止まってしまったため、新しいドキュメント生成ツールを導入しよう！ということになりました。 導入の条件は色々ありましたが、今回導入に至ったのは「MKDocs」です。 簡単で、プラグインの豊富さやモダンな見ため、既存のドキュメントよりも見やすくなったのが決め手でした。 MkDocs の導入については、すでに弊社しんや (shinyaa31) による導入手順ブログ「プロジェクトドキュメント構築向け静的サイトジェネレータ『MkDocs』及び『Material for MkDocs』の