はてなブックマーク

はじめに カミナシでID管理・認証基盤を開発しているmanatyです。ラスベガスで開催されているAWS re:Invent 2024に初めて参加しています。今回はワークショップセッションとして開催された「Secure containers from supply chain attacks」に参加したレポートをお届けします。 SBOMによるサプライチェーン攻撃対策 ソフトウェアにおけるサプライチェーン攻撃とは、ソフトウェアのビルドやデプロイを含むライフサイクルの過程を侵害して不正なソフトウェアを注入し、利用者に正規のソフトウェアとして悪意ある機能やデータが含まれたソフトウェアを提供する攻撃のことです。 supply chain attack - Glossary | CSRC サプライチェーン攻撃は、2022年の米国大統領令14028で組織に対するサプライチェーン攻撃対策の要件を定めたこと

はじめに カミナシでID管理・認証基盤を開発しているmanatyです。ラスベガスで開催されているAWS re:Invent 2024に初めて参加しています。今回はワークショップセッションとして開催された「Scaling multi-tenant SaaS with a cell-based architecture」に参加したレポートをお届けします。 Cell-based Architectureとは Cell-based architectureはスケーラビリティと耐障害性を高めるために考えられたシステムアーキテクチャです。一般にマルチテナントアーキテクチャはインスタンスやコンテナが複数存在するとしても論理的には単一のアプリケーションとデータベースで構成されています。したがって、本質的にアプリケーションやデータベースはそれぞれが論理的な単位での単一障害点となるほか、特定のテナントの過度な

こんにちは！カミナシで Engineering Manager をしております Keeth こと桑原です．今年もカミナシ社で11/14-15 の２日間，開発合宿を開催しましたので今回はそのレポートとなります！ 開催概要 日程：11月14日 12:30 〜 11月15日 15:30 場所：熱海 参加者：エンジニア21名（内，リモート参加者2名） ※カミナシに在籍しているエンジニアは合計30名ちょっといます 今回の開発合宿のコンセプトとしては， チームを超えた交流・親睦を深めることでお互いを知る としました． 現在のカミナシはマルチプロダクト戦略に舵を切っており，プロダクト毎にチームがパキッと分かれております．そのため，横の連携やノウハウ，情報の共有の重要性を強く感じるようになりました．またエンジニアメンバーも増えてきたことにより，話したことのない人も増えております． このような背景から，「相

はじめに カミナシでソフトウェアエンジニアをしている Taku(X アカウント)です。 カミナシではプロダクトのインフラに AWS を利用しているのですが、その学習の一環として AWS が主催するイベントに業務時間を利用して参加させていただいてます。 今年は AWS Jam / GameDay というイベントに計3回参加してみて、学びが多いイベントと感じたため共有させていただきたいと思います。 参加したイベント 2024/6/20：AWS Jam（in AWS Summit Japan） 2024/6/21：AWS GameDay（in AWS Summit Japan） 2024/8/26：AWS AI GameDay イベントの内容についてはネタバレ防止で公開不可のため、本記事には技術的な細かい話は出てきません。 その分ライトに読めると思うので、聞いたことがあるけど参加したことがないと

初めまして！10 月にカミナシへ入社した いちび(@itiB_S144) です。セキュリティエンジニアリングユニットに所属しつつ、8 月にリリースしたばかりの カミナシ従業員 の開発に携わっています。 先日社内エンジニア向けのセキュリティ競技会「第 2 回ごーとんカップ」を開催しました。ごーとんカップとは、社内のエンジニアが集まって CTF（Capture The Flag） 形式でセキュリティに関する問題、カミナシの開発に関わる問題を一人ひとりが解いて得点を競う大会です。CTFとは、セキュリティなどに関する問題を解いて隠されたキーワード（フラグ）を取得する競技です。 今回は、その運営を担当したので、その様子を紹介します。 ごーとんカップの目的と概要 ごーとんカップはカミナシのエンジニアリング組織におけるセキュリティ文化の醸成を目的としています。カミナシのエンジニア全員参加で、まとまった時

こんにちは、「カミナシ 従業員」サービスチームのソフトウェアエンジニアの a2 (A2hiro_tim) です。 早速ですが、ウェブアプリケーション開発、特に Go 言語を使っている方は、テストをどのように書いていますでしょうか。 我々のチームはバックエンドに Go を採用しており、 Table Driven Test （以下 TDT ）を使っていました。Go を採用した開発では TDT が広く採用されており、我々も慣習に則るのが最善だと判断したからです。 しかし実際に開発を進めると、ことウェブアプリケーション開発における TDT にはいくつか課題を感じるようになりました。そこで我々のチームでは runn というツールをテストに活用する方針に切り替え、その結果、開発を加速し、価値提供も早くすることができました。 本記事では、TDT の課題、runn の採用経緯、その後について我々のチームの

はじめに カミナシでID管理・認証基盤を開発しているmanaty（@manaty0226）です。 カミナシではAmazon Web Services（AWS）上で認証基盤を構築して動かしています。特にOpenID Providerのコア機能含めて内製しており、さまざまなOAuth拡張仕様を駆使してお客様の要求やプロダクト機能の実現に寄与しています。今回は、相互TLS（mTLS: mutual Transport Layer Security）と呼ばれる、クライアントとサーバーがともに証明書を提示して安全に接続する技術に立脚したRFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens（以下、OAuth mTLSと呼びます）を実現するために検討した内容を書きます。 仕様自体の話

こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 「円安を乗り越えるための Arm アーキテクチャへの移行が完了！ そのプロセスを公開します」にも書いたとおり、カミナシではほぼすべてのコンピューティングに Arm アーキテクチャを採用しています。また、運用コストを下げるために AWS Fargate を最大限活用しています。 Fargate には Fargate Spot という選択肢があります。 EC2 のスポットインスタンスと同様のコンセプトで、次のような特徴があります。 AWS クラウドの空きキャパシティを活用してタスクを実行 キャパシティが逼迫すると 2 分前の通知とともに停止させられる コストは Fargate と比べて 7 割引（東京リージョンの場合） 高い可用性を求められない環境では Fargate Spot を使ってコストを抑えたいところですが

どうも Security Engineering の西川です。好きなポケモンはクワッスです。カミナシ社内に遂にポケモンカード部ができまして、部員同士切磋琢磨し始めています。いつか企業対抗ポケモンカード大会をするのが夢です。 さてさて、皆さんは AWS WAF（Web Application Firewall、以下 WAF）を使っていますか？サービスに WAF を導入する際は一定期間 COUNT モードで運用することがセオリーとされています。では、COUNT モードから BLOCK モードに切り替える時に何をもって BLOCK モードへの切り替えを判断していますか？ 本記事はつい先日リリースされたカミナシ従業員というサービスを開発しているメンバーから「WAF（Web Application Firewall） を COUNT モードで動かして一定期間経ったのだけど、どのルールを BLOCK

こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは、クラウドインフラストラクチャに AWS を採用していますが、昨今の円安を受けて円換算での請求額は右肩上がりで増え続けています。サービスの規模や特性に関わらず、パブリッククラウドを利用する多くの日本企業で頭痛の種になっているのではないでしょうか。 円安になる前から継続的にコスト最適化には取り組んできましたが、クイックウィンで実施できるものはやり尽くしており手詰まり感がありました。しかし、我々スタートアップにおいて適正なコストに抑えることはランウェイ（キャッシュ不足に陥るまでの残存期間）を伸ばす意味でも重要なため、現状に甘んじることなく次の最適化ポイントを探していました。 Arm アーキテクチャ移行によるコスト最適化への期待値 AWS は Arm ベースの Graviton プロセッサを開発しており、

こんにちは、新規プロダクトの開発をしています、a2 （@A2hiro_tim ）です。 昨日、開発してきたプロダクトについて、正式リリースを発表させていただきました 🎉 prtimes.jp employee.kaminashi.jp さて、新規プロダクトの立ち上げは、技術選定や運用ツールの自由度が高く、どの監視ツールを使うか、選択に迷うこともあると思います。 我々のチームでは複数ツールの使用経験はあるものの、特定のツールの導入経験や深い知見があるメンバーはいなかったので、フラットに比較検討し、 Amazon CloudWatch の利用から始めてみよう、と意思決定しました。 主な選定理由は、 AWS エコシステムの中で完結できるため、Terraform Cloud などの既存の設定を流用できて新しく覚えることが少ない、AWS 上でコストを一元管理できる、等のメリットがある。 サービス開

どうもセキュリティエンジニアリングの西川です。 先日、株式会社Flatt Security のCCO豊田さんにお誘いいただき、カミナシのセキュリティの取り組みや開発生産性をどのように考えているかをファインディ株式会社主催の開発生産性Conference 2024 にてお話させていただきました。 当日の資料は下記です。 speakerdeck.com ※自動でライトがつく OR 無灯火を知らせるのページで左側の運転手が寝ていますがそれに意味はありません どういうことを話したか ざっくりですが、下記のような話をしました カミナシのサービスのセキュリティのオーナーシップは開発者が持っている セキュリティエンジニアリングはイネーブルメントの役割を担っている どうして Flatt Security 社の脆弱性診断を選んだか セキュリティは力を持っているからこそ生産性を奪いかねない ところで、セキュリ

はじめに こんにちは！社内の「エンジニアブログの更新を絶やさない会」の方から圧を激を貰っている Keeth こと桑原です！現在はEngineering Manager の見習いをしております． 私が所属しているサービスの開発運用に携わるチーム(Eng + PM + PD で構成。以下「サービスチーム」)では，OKR（目標と成果指標）を設定して取り組んでいます．本記事では， KR に盛り込んだ「変動係数」というあまり聞き慣れない指標を導入してみた感想や，その運用方法について振り返りたいと思います．他のエンジニアチームの運用の参考になれば幸いです． ※だいぶ文字文字しい記事になっています どのような KR をたてたのか？ 前クォーターでは，サービスチームにおけるエンジニアリングの KR を定め，定期的に振り返りながら達成を目指していました．KRの内容は以下の通りです． 6月末のコード変更差分の

はじめに こんにちは。昨年の10月にカミナシに入社したソフトウェアエンジニアの tokuse です。 気が付けば入社してから既に半年以上経っており、光陰矢の如しで驚愕しています！ カミナシではフロントエンドを TypeScript で開発しています。そんな中、先日 Object.keys() の仕様に起因する不具合が発生し、その際に Object.keys() が返す配列の順序に関する仕様について詳しく知りました。当稿ではその仕様について説明します（ECMAScript 最新前提です）。 はじめに 問題となった処理 Object.keys() の仕様 まとめ 余談 おわりに 問題となった処理 まず、問題となった処理をサンプルコードで紹介します。次のコードは、オブジェクトの数値キーのうち最大値を取得しようとした処理です。 type UserId = number; type User = {

はじめに Presigned URL（*) などで、Amazon S3 へのアップロード処理を実装していると、大きなサイズのファイルをアップロードしようとしたときに、以下のような課題に直面することがあります。 一回のPUT リクエストでアップロードできるサイズの上限が 5GB まで 単一の HTTP リクエストでアップロードするため、大きなサイズをアップロードしようとしたときに問題が起きる。例えば、アップロードの処理の途中で失敗したとき、最初からやり直しになる。 このようなときに活用したいのが、マルチパートアップロードです。マルチパートアップロードとは、その名の通り、アップロード対象のオブジェクトを小分けにしてアップロードする方法です。 AWS の SDK には、マルチパートアップロードが簡単に行えるような API が用意されているものの、多くは、S3 にアップロードを行うことができる I

どうもこんにちは西川です。AWS Community Builder に選ばれたからにはAWSのこともアウトプットしなきゃということで、今日は Security Hub の Central configurationの素晴らしさをお伝えしたいと思います。 Security Hub 運用の課題と Central configuration Cental configuration は re:Invent 2023 で発表された機能で、実は最近までこの機能が追加されていたことに西川は気づいておりませんでした（汗） でも、この機能はSecurity Hubを運用していくうえでは欠かせない機能で、それはなぜかというと、Automation rules では、OU単位だったり、アカウントについているタグ等を判別してルールを書くことができないのですが、AWSアカウントをOrganization管理して

息子に「お父さんカエルの匂いがする」と言われているセキュリティエンジニアリングの 西川です。カエルの匂いとはこれ如何に。。 カミナシに関わって1年経って 見出しで入社してではなく、関わってと表現したのは業務委託で関わり始めたのが去年の4月からだったからです。1年経って色々と今までの活動などの振り返りをしたいと思い筆を取りました。 そもそも振り返るきっかけとなったのは、IssueHunt 社のイベント（https://issuehunt.jp/seminar/lounge3）でプロダクトセキュリティについて話をする機会があったからです。できるだけ無意識下にあったものを言語化したいなと思いました。自分の考えを整理する貴重な機会をいただけて本当にありがたかったです。 私はセキュリティに関する競技への参加などを通じてチームビルディングないしは、組織に馴染むといいますか、その組織に最適化するのが得意

こんにちは！ カミナシでエンジニアリングマネージャーとして働いております、吉永です。 先日、 3/21 に Findy さんが主催の「TechBrew in 東京 〜mtx2sさんと考えるコード品質とビジネスインパクト〜」というイベントに参加してきました。 findy.connpass.com イベントにブログライティング枠なるものがあったので、この枠での参加ではないものの、参加レポートを書いてみます。 動機 mtx2s さんの記事は以前から参考にさせていただくことが多くて、毎回首がもげそうになるくらいの共感や学びを得られていました。自分自身のマネジメントの参考にもしています。いつかお会いしてみたいものだなと思っていたところ、偶然このイベントが開催されることを知り、すぐに参加を決意した次第でした。 イベントのテーマも今の私にうってつけのものでした。私の担当するチームが提供するサービスは20

はじめに こんにちは。カミナシでソフトウェアエンジニアをしている佐藤です。 みなさんは、アプリケーションのフロントエンドから、Amazon S3 にファイルをアップロードするときに、どのような方法を用いているでしょうか？ 「バックエンドのサーバーにファイルを送信し、バックエンドのサーバー経由で S3 にアップロードしている」「Presigned URL を払い出して、フロントエンドから直接 PUT している」など、いくつかの方法があると思います。 弊社で提供しているサービス「カミナシレポート」でも、用途に応じて上記の方法を使い分けて S3 へのファイルのアップロードを行っています。 特に、Presigned URL は、手軽に利用できる上に、バックエンドのサーバーの負荷やレイテンシーの削減といったメリットも大きく、重宝しています。 一方で、その手軽さの反面、アップロードに際して様々な制約を

こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは職能別のチーム分けをしておらず、エンジニアのロールは基本的に全員ソフトウェアエンジニアです。フロントエンドやバックエンドにとどまらずインフラやセキュリティも含めて、サービス開発チームがすべてを担っています。 CTO の言葉を借りるなら「システムのライフサイクル全体を見る」のがカミナシにおけるソフトウェアエンジニアであり、単一のチームで顧客への価値提供ができる体制を目指しています。 type.jp しかし、個々人のスキルマップを見るとインフラ領域を得意とするメンバーが少なく、インフラの改善は後回しになっていました。 私は前職で 6 年ほど SRE として働いていたので、入社時点からインフラの改善にも着手しなければと感じていました。しかし、専任チームが存在しないカミナシでの取り組みは、まさに試行錯誤の連

どうもセキュリティエンジニアリングの西川です。 暖かい日と寒い日の寒暖差が激しく体がおかしくなりそうですが今のところ健康を維持しております。体もセキュアでありたいものです。 今期のセキュリティ施策の検討 新年を迎え、この半期セキュリティエンジニアリングとして何をやっていくか？を「セキュリティ戦略会議」と銘打ってオフサイトで話し合いました。 そんな目的で始まった話し合いですが、結果的には時間が足りず、どういう方向性でカミナシのセキュリティを高めて行くかというところにとどまりましたが、良い話し合いができたので共有したいと思います。 この話し合いは、CTOのトリ、それからコーポレートITのメンバーと、業務委託としてセキュリティエンジニアリングを支えてくれる濱野さん、そしてこの記事を書いている西川の4名で行いました。 未来からの逆算 今期のセキュリティ施策を考えていく時に、まずは未来にどういう状態

こんにちは、カミナシのソフトウェアエンジニアの内田 (@A2hiro_tim) です。 11/28、AWS の CEO Adam Selipsky 氏の Keynoteで Amazon Q が発表されましたね。 今回ありがたいことに、AWS re:Invent 2023 にラスベガス現地で参加する機会をいただき、複数のセッションに加え、この Keynote も聞いてきました。 Amazon Q についての情報はまだ多くないですが、Amazon Q の中でも、"Amazon Q for general business use" と呼ばれる機能について、現地のセッションで聞いた話が面白かったので、書いてみたいと思います。 Keynote の様子 私は大学院で機械学習の研究室に所属していて、同時期に AI コンサルティングの会社でインターンもしていました。卒業後はソフトウェアエンジニアとしてキ

こんにちは。カミナシにて業務委託としてフロントエンドを担当している田村(@junkboy0315)です。皆さんはフロントエンドのテスト、どのように取り組んでいますか？フロントのテストはなかなか難しいですよね。 バックエンドのテストには、「入力、出力、永続化されたデータ」の3つを検証するという基本セオリーがあります。しかし、フロントエンドのテストは、その粒度や手法が多様で、とっつきにくいと感じる方も多いのではないでしょうか。 カミナシでもフロントエンドのテストは以前は十分とは言えない状態でしたが、これまで継続的に改善を重ねてきました。今回は、その変遷についてお話ししようと思います。 夜明け前 カミナシのコードベースでは、元々ユニットテストがある程度整備されていました。これらは主に複雑な計算処理を行い結果を返す関数などに対して実施されていました。 しかし、画面全体の機能を網羅する包括的なテスト

どうもセキュリティエンジニアリングの西川です。 12/3(UTC)現在まだラスベガスにいます。これが今回のラスベガスで書く最後のブログとなります。 最高の仲間たちと過ごせて最高の1週間でした。笑いすぎてお腹が筋肉痛です。 たくさんのお土産話ができましたので、日本に帰った際は聞いていただけると嬉しいです。 ラスベガス最後は「セキュリティの自動化」について話をしていきたいと思います。セキュリティの自動化といってもAWS環境の話で、コンプライアンス違反があったら自動的に修復したりするもののことを言っています。 どうしてこうも世の中、「セキュリティの自動化」の話が多いのだろうと思いながら色々なセッションを聞いていました。そして、「セキュリティの自動化は本当に必要なのだろうか？」と、ここラスベガスで自分の中であれやこれやと考えていて、最終日に「SEC327-R1: Speed up cloud se

ソフトウェアエンジニアの鈴木(@szk3)です。この記事は re:Invent の現地 ラスベガス からお届けしています。 唐突ですが、re:Invent 2023 にて行われた AWS GameDay Championships 2023 というグローバルな舞台で優勝🥇することができました ＼ やったー 🙌 ／ ということで 本記事では、現地でGameDayに参加する際の知見をシェアしたいと思います。 本文に行く前に最初にお伝えしておくと、GameDayに参加する誓約としてゲーム内容の共有は禁止されていますので、どんなゲームだったのかについては触れませんのでご了承ください。 この記事が、今後 ラスベガスでGameDayに参加してみたい！と思っている方の参考になれば幸いです。 ではでは、早速いってみよー AWS GameDay とは まずは、そもそもGameDayとは何なのか？について

こんばんは（？）、セキュリティエンジニアリングの西川です。 re:Invent始まりましたね。 カミナシからも今年は4名参加して、AWSの知識・技術向上のためさまざまなセッションに参加しています。 私は今回re:Inventは初参加で、右も左もわからない状態ですが、その中でも特に楽しみにしていたセッションがありまして、それが「COP402: Coding for compliance at scale」でした。 このセッションはレベルが400（Expert）という一番高いものでしたが、コードを見ながら解説がされていくため元々開発者だった私にとっては非常にわかりやすかったのと、 RDK（AWS Config Rule Development Kit）を試そうとして色々と調べていたので、英語はあまり得意ではないのですが理解することができました。 AWS Configのカスタムルールが書けるのは

こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは RDB に Amazon Aurora MySQL を使っています（以下 Aurora と略します）。また、データ保護の追加レイヤーとして KMS を使って DB クラスターを暗号化しています。 docs.aws.amazon.com ここまでは良いのですが、KMS キーに AWS マネージドキーが設定されていました。普段から AWS を使っている方であれば「あちゃ〜」と思われるでしょう。 なぜ Aurora の KMS キーに AWS マネージドキーを使うのが「あちゃ〜」なのか KMS キーには、AWS マネージドキーとカスタマーマネージドキーの 2 種類があります。 AWS マネージドキーはユーザーに代わって作成されるキーで、RDS の場合は aws/rds というエイリアス名が付いています。

こんにちは、セキュリティエンジニアリングの西川です。 カミナシのエンジニアリングチーム向けにセキュリティ競技会「ごーとんカップ」を開催しました。ごーとんというのはカミナシのヤギのキャラクターです。非常にかわいいですね。 開催のきっかけ 今回の取り組みは取締役CTOの原トリ（以下トリ）と「Hacktoberfest（https://hacktoberfest.com/ ）みたいなのしたいよね」という軽いノリから始まったのですが、いわゆるCTFをエンジニアリング向けにやっても意味がないので、あくまでも教育の機会になることを目的としコンテンツを検討していきました。合わせてモチベーションアップのために、参加者特典や優勝者特典でTシャツやステッカーを制作しました。結果的にこれは大正解だったと思います。あるとないとではイベントのクオリティが全然違うと実感しています。 出題コンセプトと感想 今回の取り組