並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 296件

新着順 人気順

IDaaSの検索結果1 - 40 件 / 296件

  • Webサービスにおけるログイン機能の仕様とセキュリティ観点 - Flatt Security Blog

    はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 本稿では、Webアプリケーション上で実装される「ログイン機能」の実装パターンをいくつか示し、その「仕様の中で起きうる脆弱性」とその対策について解説していきます。 「ログイン機能」はToB、ToC問わず多くのWebアプリケーションで実装されている機能で、XSSやSQL Injection、Session Fixationといったような典型的な脆弱性の観点については、なんらかの解説を見たことのある方も多いと思います。 しかし、「仕様の脆弱性」というのはあまり多く語られていない印象です。今回はそのようなタイプの脆弱性についての解説を行います。なお、IDaaSを用いずに自前でログイン機能を実装しているケースを複数パターン想定しています。 はじめに ログイン機能の仕様パターンとセキュリティ

      Webサービスにおけるログイン機能の仕様とセキュリティ観点 - Flatt Security Blog
    • コロナ禍 → リモートワークをきっかけに、趣味も仕事も楽しめる欲張りな家を建てた【エンジニア、家を建てる】 - MY HOME STORY │スーモカウンター注文住宅

      職業柄、「よりよいもの」や「よりよい環境」を求める方が多いエンジニア。そんなエンジニアの「家づくり」にはきっと、さまざまなこだわりが詰め込まれているはず。 注文住宅を選んだエンジニアに登場いただく「エンジニア、家を建てる」。第2回はrela1470(渡辺 淳)さんに寄稿いただきました。 rela1470さんが注文住宅を購入したのは、新型コロナウイルスの感染拡大でリモートワークがメインとなったことがきっかけ。ワークスペースはもちろんのこと、サウナルームや防音室なども導入し「仕事」と「趣味」どちらもとことん楽しめる空間を手に入れました。 東京・表参道の株式会社KyashというFintech企業で、コーポレートエンジニアをしているrela1470と申します! 2021年5月、茨城県取手市に念願の一戸建てを手に入れ、妻と2人で楽しく暮らしています。 業務内容にいわゆる情シス業が含まれているため少な

        コロナ禍 → リモートワークをきっかけに、趣味も仕事も楽しめる欲張りな家を建てた【エンジニア、家を建てる】 - MY HOME STORY │スーモカウンター注文住宅
      • 2020年のフロントエンドエンジニアの技術スタックの一例

        年の瀬なので、私自身が今年利用した技術をベースに技術スタックをまとめてみようと思います。 とはいえ Web Standard といった広い対象から、フレームワークやライブラリまで、粒度の違うものを全て言及するのは無理があるというもの。特に強く言及できるものは個別で説明しつつ、最後に利用する機会がなかったものも最後に記載する形で。 以下常体。 追記: マイナー企業のようなので一応書いておきますが、筆者は本業ではLINE株式会社という組織でいわゆるエンジニアリングマネージャーと言われるような業務とその採用に関わる仕事をしています。 利用した技術一覧 HTML/CSS/JS みたいなことを書いてるとキリがないので、独断と偏見で区分けして適宜漉いています。特に利用する機会が多かったものは太字でピックアップ。 Frontend Language/Platform TypeScript JavaScr

          2020年のフロントエンドエンジニアの技術スタックの一例
        • 仮想サーバ17万台、物理サーバ9万台 「ヤフオク!」「Yahoo! JAPAN」を支えるヤフーのITインフラ運用術

          仮想サーバ17万台、物理サーバ9万台 「ヤフオク!」「Yahoo! JAPAN」を支えるヤフーのITインフラ運用術(1/2 ページ) 国内最大級のポータルサイト「Yahoo! JAPAN」をはじめ、ECサイト「Yahoo!ショッピング」やオークションサイト「ヤフオク!」など、コンシューマー向けWebサービスを数多く運営するヤフー。同社はこれらのサービスを裏で支えるシステム基盤として、大規模なプライベートクラウド環境を自社で構築・運用している。 ヤフーの奥村司さん(クラウドプラットフォーム本部 プライベートクラウドチーム リーダー)が、クラウドインフラの運用管理者向けイベント「Cloud Operator Days Tokyo 2020」で明かしたところによると、その規模は、仮想サーバが約17万台、物理サーバが約9万台。物理サーバのうち2万台がIaaSの仮想化ハイパーバイザーとして使用されて

            仮想サーバ17万台、物理サーバ9万台 「ヤフオク!」「Yahoo! JAPAN」を支えるヤフーのITインフラ運用術
          • え、HTTPSの転送なのにファイルも暗号化するんですか???

            TL;DR 基本的には二重での暗号は不要 ただし、転送後も暗号化したまま使うなら、転送前から暗号化するのは良い ルールXを無邪気に追加して不整合のあるセキュリティルールを作ってはいけない はじめに 社内のセキュリティルールやスタンダードを決めるときに、HTTPSなのにVPN必須になってたりファイル暗号も必須になってたりするケースたまに見ます。今回は、それは実際に必要なことなのか? セキュリティ的に有効なのか? という点で考察をしていきたいと思います。 背景 二重三重に暗号化しても性能ペナルティが無いなら「なんとなく安全そうだから」でOKにしてしまいがちなのですが、これはよく考える必要があります。 というのも 「ルールXを追加することで既存のルールAと不整合が出る」 ってことは割とよくあるからです。具体的には「SCPのファイル転送は(SCPのセキュリティに不備があった時の)安全性のためにファ

              え、HTTPSの転送なのにファイルも暗号化するんですか???
            • 何故パスワードをハッシュ化して保存するだけでは駄目なのか? - NRIネットコムBlog

              不正アクセスによるIDとパスワードの漏洩を受けて、MD5によるハッシュ化について話題になっていました。システムを作る上で、パスワードの管理や認証はどう設計すべきかを考えるために、少し整理をしてみます。もし事実誤認があれば、どしどしご指摘ください。 == 2023/8/21追記 == この記事は、ハッシュの保存の仕方一つとっても、沢山の対策方法が必要であるということをお伝えするために記載しています。そして、これから紹介する手法を取れば安全とお勧めしている訳ではないので、その点をご留意いただければと思います。攻撃手法に応じての対応策の変遷を知っていただくことで、セキュリティ対策は一度行えば安全というものではないことを知って頂くキッカケになれば幸いです。 == 追記終わり == パスワードのハッシュ化 まず最初にパスワードの保存方法です。何も加工しないで平文で保存するのは駄目というのは、だいぶ認

                何故パスワードをハッシュ化して保存するだけでは駄目なのか? - NRIネットコムBlog
              • Webアプリケーションのセッション管理にJWT導入を検討する際の考え方 - r-weblife

                おはようございます、ritou です。 qiita.com これの初日です。 なんの話か 皆さんは今まで、こんな記事を目にしたことがありませんか? Cookie vs JWT 認証に JWT を利用するのってどうなの? JWT をセッション管理に使うべきではない! リンク貼るのは省略しますが、年に何度か見かける記事です。 個人的にこの話題の原点は最近 IDaaS(Identity as a Service) として注目を集めている Auth0 が Cookie vs Token とか言う比較記事を書いたことだと思っていますが、今探したところ記事は削除されたのか最近の記事にリダイレクトされてるようなのでもうよくわからん。 なのでそれはおいといて、この話題を扱う記事は クライアントでのセッション管理 : HTTP Cookie vs WebStorage(LocalStorage / Sess

                  Webアプリケーションのセッション管理にJWT導入を検討する際の考え方 - r-weblife
                • 認証と認可と課金とコアドメインを分離したシステムは勝てるという話 - まっちゅーのチラ裏

                  自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく 分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。 だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。 戦術的DDD的観点での関心事の分離によるメリットとは コンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか?」を都度考えることを強制することができる。 境界がなければ意図しない密結合を生みやすくなってしまう。 もちろん、境界を超える

                    認証と認可と課金とコアドメインを分離したシステムは勝てるという話 - まっちゅーのチラ裏
                  • 100万ユーザーをログアウトさせずに新認証基盤に移行した話

                    即戦力人材と企業をつなぐ転職サイト「ビズリーチ」は2009年にサービスを開始し、スカウト可能会員数は190万人以上(2023年1月末時点)のユーザーにご利用いただくサービスに成長しました。 今回、その「ビズリーチ」の認証基盤としてIDaaS(Identity as a Service)のOkta Customer Identity Cloud(Powered by Auth0)(以下Auth0という)の導入を行いました。 本記事では認証基盤を刷新するに至った背景とAuth0を用いて100万を超えるユーザーをログアウトさせることなく移行した方法についてご紹介いたします。 前提 本記事で得られる情報 本記事を読むことで以下のような情報を得ることができます。 IDaaSを選ぶ理由 IDaaSを用いて認証・認可を運用中のプロダクトに組み込んだ事例 運用中のプロダクトに組み込む際に発生しうる課題と対

                      100万ユーザーをログアウトさせずに新認証基盤に移行した話
                    • 2019年のDevOps/MLOpsエンジニアの標準的スキルセット - Qiita

                      ちなみに、IT業界全体のシェアとしてはMicrosoftのAzureの方がGCPを上回っていますが、Web業界においてIaaSにAzureを採用している企業さんは2019年時点ではまだまだ少ないので、現状ではとりあえずAzureへのキャッチアップは後回しにしておいて問題ないと思われます。 クラウドアーキテクチャ設計 前述したAWSやGCPの各種マネージドサービスを適切に組み合わせてアーキテクチャ設計を行い、それを構成図に落とし込める能力は必須となります。 いわゆる「アーキテクト」という職種の担当領域でもありますが、「サービスを安定稼働させたまま、バリューをユーザに迅速に届ける」ためには、自動化のしづらい構成が採用されてしまったり、無駄な機能が開発されてしまったり、アンマネージドなツールやサービスが使用されて管理工数が肥大化したりしないように、アーキテクチャ設計の段階からDevOpsエンジニ

                        2019年のDevOps/MLOpsエンジニアの標準的スキルセット - Qiita
                      • 【レポート】AWS における安全な Web アプリケーションの作り方 #AWS-55 #AWSSummit | DevelopersIO

                        この記事では、5月12日に行われた AWS Summit Online 2021 のオンラインセッション『AWS における安全な Web アプリケーションの作り方(AWS-55)』の模様をレポートします。 セッション概要 情報処理推進機構(IPA) の公開している「安全なウェブサイトの作り方」をはじめとしたセキュリティを考慮した安全なウェブアプリケーションの設計ガイドラインがいくつか知られています。本セッションでは、アプリケーション開発者向けにガイドラインに則ったアプリケーションを AWS 上でどのように実装するのかを AWS プラットフォームレイヤーとアプリケーションレイヤーのそれぞれの観点から項目ごとに解説し、アプリケーション導入前、または導入後のセキュリティ対策の指標となることを目指します。 登壇者 アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテク

                          【レポート】AWS における安全な Web アプリケーションの作り方 #AWS-55 #AWSSummit | DevelopersIO
                        • Firebase Authentication 7つの落とし穴 - 脆弱性を生むIDaaSの不適切な利用 - Flatt Security Blog

                          はじめに こんにちは、株式会社 Flatt Security セキュリティエンジニアのぴざきゃっと (@pizzacat83) です。 認証機構を自作せずに導入できる Firebase Authentication は様々なアプリケーションにて利用されていますが、その特性を十分に理解せずに導入すると、実は不具合や脆弱性が生じることがあります。そこで本稿では Firebase Authentication を利用するうえで、注意しなければ不具合や脆弱性に繋がりうる 7 個の「落とし穴」について解説します。 はじめに IDaaS の利点と欠点 落とし穴 1. 自己サインアップ リスク 対策 不十分な対策 落とし穴 2. ユーザーが自身を削除できる 対策 落とし穴 3. 他人のメールアドレスを用いたユーザー登録 リスク リスク 3-1. メールアドレス誤入力によるユーザー乗っ取り リスク 3-2

                            Firebase Authentication 7つの落とし穴 - 脆弱性を生むIDaaSの不適切な利用 - Flatt Security Blog
                          • 認証用トークン保存先の第4選択肢としての「Auth0」

                            iCARE Developer Meetupは、月次で開催している株式会社iCAREが主催するエンジニア向けのLT勉強会です。18回目の今回は、Ruby on Railsをテーマに行いました。サーバーサイドエンジニアの越川氏からはToken認証機能について。 Rails APIモードで開発するときの認証用のトークンはどこに保存すればいいの問題 越川佳祐氏:私からは、「Rails APIモードにおけるToken認証機能について」というテーマでLT(ライトニングトーク)をしようと思っていたんですが、スライドを作っていて「あれ、これ別にRailsだけの話じゃなくない?」と思ってしまいました。みなさんの中にも、そう思う方がいるかもしれないんですが、もうこれで作っちゃったのでご了承ください。 私は株式会社iCAREで、サーバーサイドエンジニアをしている、越川と申します。Twitterは@kossy0

                              認証用トークン保存先の第4選択肢としての「Auth0」
                            • AWSマルチアカウントにおけるIAMユーザー設計戦略を考えてみる - How elegant the tech world is...!

                              はじめに 2020年3月以来の投稿になりますが、「AWS案件に携わる中で、いろいろと貯まった知見を世のエンジニアの皆さんと共有したいな..」という思いに突然駆られ、本稿ではAWSマルチアカウントにおけるIAMユーザ設計の戦略をご紹介します。 ビジネスの要件・制約等により、取り得る設計は様々ですが、一つのベストプラクティス例としてご参考になればと思います。 IAMポリシーに関する基本方針 カスタマー管理ポリシーの利用 AWS利用において、避けては通れないIAM設計。 AWSでは、AWSアカウント(ルートユーザー)の通常利用は推奨しておらず、 AWSアカウント作成後は速やかにIAMユーザーを作成される方も多いのではないでしょうか。 AWS アカウントのルートユーザー 認証情報を使用して AWS にアクセスしないでください。また、認証情報を他のだれにも譲渡しないでください。代わりに、AWS アカ

                                AWSマルチアカウントにおけるIAMユーザー設計戦略を考えてみる - How elegant the tech world is...!
                              • 多要素認証を私物スマホでやっていいのか問題

                                Hello,World! gonowayです。 弊社がご支援するお客様とお話するなかで、多要素認証のためにIDaaSが提供しているアプリケーション(以降、認証アプリ)を私物モバイル端末にいれていいのか?という疑問に、わたしたちが普段お客様にご案内していることをざっくりまとめてみました。 3行まとめ 現代では外部の不正ログインから守るために多要素認証が必須になってきている。 多要素認証の実現のため、会社モバイル端末であれ私物モバイル端末であれ認証アプリはインストールしてほしい。 私物モバイル端末にインストールしてもらう場合、エンドユーザーへの説明を行うことが必要。また、ガラケーしか持っていないような例外措置への対処を考えることも必要。 前提 認証要素について 認証要素は下記の3種類です。NIST SP800-63を参考にしています。 記憶によるもの:記憶(Something you know

                                  多要素認証を私物スマホでやっていいのか問題
                                • AWS 診断を事例としたクラウドセキュリティ。サーバーレス環境の不備や見落としがちな Cognito の穴による危険性 - Flatt Security Blog

                                  こんにちは。本ブログに初めて記事を書く、株式会社 Flatt Security セキュリティエンジニアの Azara(@a_zara_n)です。普段は Web やプラットフォームの診断やクラウド周りの調査、Twitter ではご飯の画像を流す仕事をしています。よろしくお願いします。 クラウドサービスが発展し続ける今日この頃、多くの企業がパブリッククラウドやプライベートクラウドなどを駆使し顧客へサービス提供しているのを目にします。そのような中で、サービスが利用するクラウドにおいて設定不備や意図しない入力、構成の不備により顧客情報や IAM をはじめとする認証情報が脅かされるケースが多々あります。 本記事では、そのような脅威の一例をもとにクラウドサービスをより堅牢で安全に利用する一助になればと、攻撃手法や対策などについて解説をしていきます。 また、私の所属する 株式会社 Flatt Secur

                                    AWS 診断を事例としたクラウドセキュリティ。サーバーレス環境の不備や見落としがちな Cognito の穴による危険性 - Flatt Security Blog
                                  • 不便で仕方ない「住所入力の全角・半角問題」はなぜなくならないのか 専門家に原因を聞く

                                    ECサイトやSaaSのアカウントを作るため、入力フォームに全角で住所を打ち込み。番地や郵便番号などの数字は半角で書き、情報を登録しようとしたら「この情報は半角では入力できません。全角で入力してください」。よく見るとページ内に「番地は全角で入力してください」という注意書きがあったので、再度打ち直し──入力フォームを使ったことがある人なら、多くの人がこんな面倒な経験を味わっているのではないだろうか。 こういった仕様は巷(ちまた)にあふれており、ネットで「全角・半角問題」などと呼ばれている。ユーザーに不便を強いているにもかかわらず、このような入力フォームはなぜなくならないのか。 この課題のソリューションとして、ユーザーが入力フォームに打ち込んだ文を自動で半角・全角に統一するなどの機能を持つJavaScriptライブラリ「InputManJS」を提供するグレープシティ(仙台市)の若生尚徳さん(ツー

                                      不便で仕方ない「住所入力の全角・半角問題」はなぜなくならないのか 専門家に原因を聞く
                                    • KyashがOneLoginを選んだ理由 - rela1470のブログ

                                      Kyashでは9月からIDaaSであるOneLoginを導入しました。 導入から3ヶ月が経過し、現時点でほぼすべての社内認証をOneLoginに統一することが出来ました! 今回は、なぜOneLoginにしたのか、使い勝手等を含めお伝えできればと思います。 すごくヨイショしている記事になってしまったんですが、お金はもらってません!!!!!笑 www.onelogin.com 公式HPにも取り上げて頂き、ありがとうございます! 実は前職でもかなり使い込んでおり、OneLoginは思い入れのあるプロダクトです。 www.pentio.com 今回の導入に関しても、OneLogin 日本代表の福見さんと代理店であるペンティオさんにかなりのお力添えを頂きました。ありがとうございます! Kyash Advent Calendar 2019 day11 ということでKyash Advent Calend

                                        KyashがOneLoginを選んだ理由 - rela1470のブログ
                                      • 入社後にAWSアカウントの整理とAWS SSOを導入した話 - トレタ開発者ブログ

                                        こんにちは、2019年7月よりトレタにJOINした @aibou です。 本記事はトレタ Advent Calendar 2019の16日目の記事です。 趣味はNFL観戦とボルダリングです。NFLは今年11月にマイナス気温の屋外で現地観戦してきました。 最近リードクライミングの講習を受けまして、ガシガシと岩を登っております。 さて、今回はAWSアカウントとAWS SSOのお話をしようと思います。 既に社内エンジニアへの共有や社内WikiにAWS SSOの利用マニュアルを残していますが、経緯や変遷について記載していないので、トレタ社員の方にも読み物として読んでいただければなと思っています。 免責事項 本記事を参考に実施したことで発生した金銭・セキュリティ等あらゆる問題について責任を負いかねますので、自己責任のもと実施していただくよう、よろしくお願いいたします。 また、誤り等あればはてブ等でご

                                          入社後にAWSアカウントの整理とAWS SSOを導入した話 - トレタ開発者ブログ
                                        • 仕様起因の脆弱性を防ぐ!開発者向けセキュリティチェックシート(Markdown)を公開しました - Flatt Security Blog

                                          はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 これまで弊社ブログでは様々な「仕様とセキュリティ観点の解説記事」を発表してきました。今回はいままでの記事を改めて紹介しつつ、読者の皆様が開発中のサービスでセルフチェックを行えるよう「仕様とセキュリティ観点チェックリスト」を作成しました。ご活用いただけると幸いです。 ダウンロードは下記のGitHubリンクよりどうぞ。 また、株式会社Flatt Securityではお客様のプロダクトに脆弱性がないか専門のセキュリティエンジニアが調査するセキュリティ診断サービスを提供しています。料金に関する資料を配布中ですので、ご興味のある方は是非ご覧ください。 はじめに アプリケーションの仕様起因の脆弱性とは アプリケーションの仕様起因の脆弱性を防ぐために 仕様の脆弱性によく見られる共通点 1. ク

                                            仕様起因の脆弱性を防ぐ!開発者向けセキュリティチェックシート(Markdown)を公開しました - Flatt Security Blog
                                          • 完全無料のIDaaS!?Google Cloud Identity Freeを試してみる

                                            Google Cloud Identity Services昨日開催された「リーグオブ情シス #7」でも紹介されていた、Google Cloud Identity Freeを試してみます。 Google Cloud Identity Freeとはデバイス管理やディレクトリ管理、SAMLを利用したSSOなどGoogle Cloud Identityのほとんどの機能を無料で利用できるライセンス体系です。 閲覧だけに限って言えば、Google Driveの共有ドライブも利用することが可能です。 作成できるユーザー数は「50」までに制限され、プロビジョニングなどはできませんが、ユーザーの組織管理という観点においてはほとんどのことを十分にこなすことが可能です。 Google Workspaceを利用している場合は、同じ組織内にユーザーを共存させることも可能なので、小さな組織でパート・アルバイトの方な

                                              完全無料のIDaaS!?Google Cloud Identity Freeを試してみる
                                            • Auth0のアクセストークンをLocal Storageに保存するのは安全?メリット・デメリットをin-memory方式と比較して検討する - Flatt Security Blog

                                              ※追記: 本記事の続編としてin-memory方式からアクセストークンを奪取するPoCを下記記事で公開しました。ぜひあわせてご覧ください。 はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事では、Auth0のSPA SDKでアクセストークンのキャッシュを有効化する際の考慮ポイントについて紹介し、それを切り口にアクセストークンの保存場所に関してin-memory方式とlocalStorage方式の2つについて解説します。 Auth0のようなIDaaSは昨今かなり普及が進んでいると思いますが、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用まで観点に含めて専門家がチェックすることが可能です。 ご興味のある方は是非IDaaS利用部

                                                Auth0のアクセストークンをLocal Storageに保存するのは安全?メリット・デメリットをin-memory方式と比較して検討する - Flatt Security Blog
                                              • Firebase AuthなどJavaScriptでAPIセッション用のトークンを得ることについて - Qiita

                                                ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう (※ こちらの参照記事の内容自体に不備があるとか甘いとか指摘するものではないんですが、勝手に枕として使わせてもらいます) 上記記事は、Firebase Authenticationが提供するJavaScript APIを使ってJWTのトークンを取得し、自前のサーバにHTTPのヘッダで送りつけて検証をさせることで、認証の仕組みをセキュアかつかんたんに実現しよう、という内容です。 このようにJavaScriptのAPIでトークンを発行して自前バックエンドのAPI認証につかう方法はAuth0のSDKなどでも行われていますので、IDaaSをつかってSPAを開発する場合には一般的なのかもしれません。 話は変わりますが、SPAの開発に携わっている方は「localStorageにはセッション用のトー

                                                  Firebase AuthなどJavaScriptでAPIセッション用のトークンを得ることについて - Qiita
                                                • AWSのマルチアカウント戦略が難しい! | DevelopersIO

                                                  今日(2022/07/07)は弊社、Classmethodの創立記念日ということで、 AWSのマルチアカウント戦略で思ったこと をそのまま書き殴ってみました。 共感するところや他に苦労しているところ思いついた方は Twitter 等で共有いただけると嬉しいです! 思いつく限り書いた結果の目次がこちらです。 「アカウントをどう分割するのか」問題 「AWS Control Tower を活用したほうがいいのか」問題 「ユーザー管理どうするのか」問題 「最小権限とは言っても」問題 「管理アカウントでの作業が怖い」問題 「OU/SCP周りの更新が怖い」問題 「セキュリティをどう向上するか」問題 「アカウント数のスケールにどう対応するのか」問題 「ベースラインの構築/管理をどうするか」問題 「ログ集約するのか/しないのか」問題 「どのアカウントかぱっと見て分からない」問題 「Security Hub

                                                    AWSのマルチアカウント戦略が難しい! | DevelopersIO
                                                  • 【PoC編】XSSへの耐性においてブラウザのメモリ空間方式はLocal Storage方式より安全か? - Flatt Security Blog

                                                    はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事は、Auth0のアクセストークンの保存方法について解説した前回の記事の補足となる記事です。前回の記事の要旨をざっくりまとめると以下のようなものでした。 Auth0はデフォルトではアクセストークンをブラウザのメモリ空間上にのみ保存するin-memory方式であり、XSSへの耐性のなさ等の理由でlocalStorageで保存することを推奨していない しかし、XSSでアクセストークンを奪取できるのはin-memory方式でも同じのはず(検証は行いませんでした)。localStorage方式を過度に忌避する必要はないのではないか なお、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用

                                                      【PoC編】XSSへの耐性においてブラウザのメモリ空間方式はLocal Storage方式より安全か? - Flatt Security Blog
                                                    • IdPとしてSAML認証機能を自前実装した - BASEプロダクトチームブログ

                                                      はじめに みなさんはじめまして。BASEでエンジニアをしております田村 ( taiyou )です。 先日、BASEではショップオーナー向けのコミュニティサイト「BASE Street」にログインするための機能としてSSOログイン機能をリリースしました。 SSOログインを実現するための認証方式はいくつかあるのですが、弊社ではSAML認証方式を用いて実現しました。 そのため、この記事ではSAML認証機構のIdPとしてOSSを使わずにSAML認証機能を実装する方法を紹介します。 前回のテックブログで、このSSOログイン機能のフロント側を開発したPJメンバーの若菜が「サーバーサイドエンジニアがフロントエンドに挑戦して最高の経験になった話」を執筆したのでこちらも見てみてください! SAML認証機能を提供しているOSSには、Keycloakなどがありますが、BASEでは以下の理由により自前実装すること

                                                        IdPとしてSAML認証機能を自前実装した - BASEプロダクトチームブログ
                                                      • Google Workspaceのプライマリドメイン変更を実施しました - Pepabo Tech Portal

                                                        こんにちは、ペパボのCorporate Engineering Group(以下CEG)でソフトウェアエンジニアをしている加治です。 CEGでは、主にペパボ社内で利用されている社内向けサービスの開発・運用・保守を行っています。運用・保守を行っているサービスの中にはSaaSも含まれています。そのSaaSの一つであり、ペパボでメインで使用されているオフィススイートであるGoogle Workspaceのプライマリドメインを変更したお話をします。 最初に、このお話のターゲットを明確にしておこうと思います。 これからプライマリドメインを変更したい情シス、コーポレートエンジニアなどの担当者 プライマリドメインを変更したことがあり、ペパボではどうだったのかな〜と気になった人 Google Workspaceの運用をしていて、プライマリドメインが事実上のメインのドメインと異なるときの影響を知っておきたい

                                                          Google Workspaceのプライマリドメイン変更を実施しました - Pepabo Tech Portal
                                                        • 経産省がゼロトラストの概念取り入れた業務環境、「イケてる」作りに驚いた

                                                          接続元のネットワークやデバイスを問わず常にアクセスを精査し、適切に認証・認可をするセキュリティーモデル「ゼロトラストアーキテクチャー(ゼロトラスト)」が注目を集める。 コロナ禍でテレワークが普及し、社外からインターネット経由でクラウドサービスに直接アクセスする企業が続出した。それに伴い、ファイアウオールで社内外のネットワークを区切り、社内は安全なものとみなす「境界型セキュリティー」ではデータを守り切れないケースが増え、ゼロトラストの注目度はさらに高まっている。 だが何か1つ製品を導入すればよいというものではない。既存の技術で完全なゼロトラストを実現するのは困難ともいわれ、雲をつかむような話に苦戦する企業は多いようだ。 そんな中、経済産業省は2021年5月12日に「DXオフィス関連プロジェクト管理業務等の効率化に関するデジタルツールの導入実証・調査事業」の報告書をソフトウエア開発プラットフォ

                                                            経産省がゼロトラストの概念取り入れた業務環境、「イケてる」作りに驚いた
                                                          • Amazon の 2段階認証 突破の噂についての仮説 と 2段階認証で意識すること【2FA/2SV/MFA】 - Qiita

                                                            Amazon の 2段階認証(2SV)が突破された? Amazon の 2段階認証(2SV) が突破されたのではないかという件が話題になっています。 私もこれについてはとても気になっており、できるだけ早く真相が解明されることを願っています。 そこで、ふと疑問に感じたことが、2SV は何をどの程度防いでくれるのかということです。 ここでは、Amazon を例に、いろんなことを考えていきたいと思います。 フィッシングの前には無力 まず、2SVの突破と言っても様々な手口があります。 徳丸先生の動画が示す通り、中継型フィッシングであれば、自ら正しい認証情報を入力することになるので、2SVを設定していようがいまいが突破されてしまいます。 フィッシングではなく、かつ、TOTPでも突破されたケースも 今回の被害者には、中間者攻撃やフィッシングを受ける状態になかったと仰っている方がいました。 なので、何か

                                                              Amazon の 2段階認証 突破の噂についての仮説 と 2段階認証で意識すること【2FA/2SV/MFA】 - Qiita
                                                            • 無料で使えるGoogleのIDaaS「Google Cloud Identity Free Edition」を利用してみた | DevelopersIO

                                                              みなさん、こんにちは! AWS事業本部の青柳@福岡オフィスです。 今回は、Googleが提供する IDaaS (Identity as a Service) である Google Cloud Identity を使い始めるまでの流れをご紹介したいと思います。 「Google Cloud Identity」とは Googleが提供するユーザーアカウントのサービスと言えば、真っ先に「Googleアカウント」を思い浮かべる方も多いのではないかと思います。 Googleアカウントと「Google Cloud Identity」は何が違うのでしょうか? 大きな違いが、Googleアカウントが個人向けのサービスであるのに対して、Google Cloud Identityは組織 (会社や学校など) 単位でユーザーアカウントの管理ができるサービスという点です。 また、Googleアカウントではユーザーアカ

                                                                無料で使えるGoogleのIDaaS「Google Cloud Identity Free Edition」を利用してみた | DevelopersIO
                                                              • ぼくのかんがえたさいきょうの個人開発あーきてくちゃ

                                                                前置き この記事で紹介するアーキテクチャはあくまで机上論であり、筆者が実際にこれらのアーキテクチャでサービスを運用したことがあるわけではありません。 そのため、考慮漏れ等あるかもしれません。その際はご指摘いただけますと幸いです。 モチベーション 個人開発でアプリケーションを作って運用したい! お金は極力かけたくない! けどいい感じのツールを組み合わせてクールなアーキテクチャにしたい! 対象とするアプリケーションの概要 ブラウザで動くウェブアプリケーション 認証機能を持つ DBはNoSQLではなくRDB アプリケーション本体とは別に管理画面アプリケーションが必要 以上を前提として考えました。 ぼくのかんがえたさいきょうあーきてくちゃ こちらです。 コンポーネントごとに解説させてください。 フロントサーバー Next.js on Vercelです。 こちらはもはや説明不要の王道構成かと思います

                                                                  ぼくのかんがえたさいきょうの個人開発あーきてくちゃ
                                                                • OAuthの言葉周りを整理する

                                                                  OAuthの仕組みとToken認証周りの言葉はいつまで経ってもはっきり理解できないものの一つでした。 しかし最近ようやく理解できるようになってきたのでとりあえずそれぞれの言葉の指すものや定義をここで整理してみようと思います。 リフレッシュトークン リフレッシュトークンとは アクセストークンの有効期限が切れたときに、認可サーバーにアクセストークンの更新リクエスト認証をするためのトークン。 OAuth自体はリフレッシュトークンがなくとも実装できるが、リフレッシュトークンはOAuthをより便利にするためのもの。 一般的に有効期限は長い。 ないとどうなるのか アクセストークンの期限が切れたらその度にSNS認証のあのログイン画面に飛ばされてメアドとパスワードの入力が必要になる。 セキュリティに関すること 有効期限が長くても安全性に問題がないと考えられる理由としては、アクセストークンの期限切れ時にしか

                                                                    OAuthの言葉周りを整理する
                                                                  • Google Cloud の IDaaS「Identity Platform」で作る、さまざまな認証パターン

                                                                    Identity Platform を使うと、さまざまな認証パターンが構築できる! この記事は2023年10月6日に行われたナレッジワークさん主催のイベント「Encraft #7 AppDev with Google Cloud」で発表したセッションの解説記事です。現地でご参加いただいた皆さん、オンラインでご視聴いただいた皆さん、ありがとうございました! 私のセッションでは Identity Platform を使ったさまざまな認証パターンについてご紹介しました。セッション後、いくつかのご質問や「こんなパターンもあるよ!」というコメントもいただきました(ありがとうございます!)。この記事では、セッション内でご紹介した内容に加え、別解、または発展系とも言えるいくつかのパターンについてもご紹介します。 Identity Platform とは まずはこの記事でメインで扱う Identity P

                                                                      Google Cloud の IDaaS「Identity Platform」で作る、さまざまな認証パターン
                                                                    • 【注意喚起】AzureADの設定適切ですか?意図しない情報公開について。 - Qiita

                                                                      Azure Active Directory (AzureAD)をご存知でしょうか? Azure ADについて 今まで企業の端末やユーザ管理をするとき使われてきた、Windows Actice Directoryのようなものですが、根本的な設計は全く異なります。SAML認証に対応していたりと、いわゆるIDaaSのようなもので、組織がクラウドサービスを利用する際のID基盤として使われています。 Microsoft Azureや組織向けOffice 365、Microsoft 365を利用している方は、ほぼ自動的にAzureADのテナントで管理されるユーザとして利用していると思います。 AzureAD知ってるよという方、会社や学校のアカウントの個人IDもAzureADを利用して払い出されている方も多いのではないでしょうか?いろんな便利なSaaSが増えてきたし、1つのアカウントで各サービスが使え

                                                                        【注意喚起】AzureADの設定適切ですか?意図しない情報公開について。 - Qiita
                                                                      • 「なぜクラウドなんだ」「今までのやり方を変えないで」――反発乗り越えAWSなど導入 京王バスを変えた男の交渉術

                                                                        「なぜクラウドなんだ」「今までのやり方を変えないで」――反発乗り越えAWSなど導入 京王バスを変えた男の交渉術(1/2 ページ) 「クラウド導入を試みた当初は、『なぜクラウドを使うのか』『今までのやり方を変える意味が分からない』などと、周囲からさまざまな反発に遭いました」――。京王電鉄の虻川勝彦氏(経営統括本部 デジタル戦略推進部長)は、12月10日に開催されたシステム担当者向けイベント「NetApp INSIGHT 2019 TOKYO」でこう語った。 【更新履歴:2019年12月12日 午後10時45分更新 追加の取材と事実確認に基づき、本文の一部を変更しました】 虻川氏は、グループ会社の京王電鉄バス(以下、京王バス)に出向していた2011年から、システム刷新プロジェクトの責任者としてクラウド導入を推進。グループウェアに「Office 365」、アプリ開発基盤に「kintone」を導入

                                                                          「なぜクラウドなんだ」「今までのやり方を変えないで」――反発乗り越えAWSなど導入 京王バスを変えた男の交渉術
                                                                        • ログ一元管理の本質とSIEMの限界 - データ基盤への道 - LayerX エンジニアブログ

                                                                          三井物産デジタル・アセットマネジメントで、ガバナンス・コンプラエンジニアリングをしている 鈴木 (@ken5scal )です。 いきなりですが、ログ管理はどの職種どの場面でも重要です。セキュリティにおいても、古生代よりサーバー、ネットワーク機器、アプリケーションなどから出力されるログを一元的に収集し、監視や分析を行うことで、セキュリティインシデントの早期発見や対応、コンプライアンス要件の達成が可能になります。 このようなログ一元管理を実現する代表的なソリューションは、そう、皆様よくご存知のSIEM。我らが「Security Information and Event Management」であります。 私はSIEMを、新卒で入社した大手企業でSOC(Security Operation Center)として触れ、その後ユーザー企業でもOSSやAWS GuardDuty(?)などの形で利用す

                                                                            ログ一元管理の本質とSIEMの限界 - データ基盤への道 - LayerX エンジニアブログ
                                                                          • 認証機能を独自実装する代わりにIDaaSのREST APIを使うアプローチ - r-weblife

                                                                            こんにちは、ritou です。 最近のあれこれでIDaaSと呼ばれる機能に注目が集まっているような気がしますが、どうしてもフロントエンドでの導入部分が目に付きます。 「新規サービスで使っていこう」ならまだしも「既存のを何とかしたい」みたいな場合にフロントエンドまでごっそり変えるのなんて腰が重くなって仕方ない感じでしょう。 そこで今回は、REST APIを用いた新規導入、移行というアプローチもあるのかなという話を書いておきます。 SPAとなると当然フロントエンドの振る舞いに注目されるけど、Deviseからの...を考える人たちはこの辺りから攻めるのもアリかと思う。ちゃんと整理して考えよう。https://t.co/fwhoA6wtjx— 👹秋田の猫🐱 (@ritou) 2020年8月19日 IDaaS の REST API この辺りをみてみてはどうでしょう。 Firebase Authe

                                                                              認証機能を独自実装する代わりにIDaaSのREST APIを使うアプローチ - r-weblife
                                                                            • LoIのさいつよの情報システムを実践していますという話

                                                                              はじめにこんにちは、Finatextでエンジニアをしている @s_tajima です。 先日、 リーグオブ情シス 第一回 スーパーリーグ #LoI というオンラインイベントが実施されていました。 詳細はconnpassのページをみていただけるとよいかなと思うのですが、簡単にいうと「僕がかんがえたさいつよの情報システム」をプレゼンテーションし合うイベントです。 そこで発表されていた、さいつよの情報システムのうち、視聴者投票で1位だった吉田さんの提案した構成が、弊社で実際に稼働させているものにすごく近しいものでした。せっかくなのでどんな点が共通していたか、どんな点が異なっていたかというのを紹介してみようかなと思います! 前提条件LoIで提示されていた前提条件は 企業規模: 100~200名業種: インターネットサービス企業 (SaaS型MAツール)一人あたり月額予算: 10,000円情シス人数

                                                                                LoIのさいつよの情報システムを実践していますという話
                                                                              • Cloud Run で作るサーバーレス アーキテクチャ 23 連発 - これのときはこう!

                                                                                2023年は「Cloud Run を触って覚える」をテーマとした ひとりアドベントカレンダー を開催しており、Cloud Run のさまざまな機能や Cloud Run でよく使う構成などをご紹介しています。 最終日、25日目は Cloud Run を中心としたサーバーレス アーキテクチャをいくつか紹介します。2023年にちなんで23個のアーキテクチャを用意しました。 Cloud Run の概要は「gihyo.jp」で解説していますので、こちらもぜひご覧ください。 Web アプリケーション + API の 3-Tier 構成 (SPA) Web アプリケーション + API の 3-Tier 構成 (SPA) SPA (Single Page Application) がフロントになり、バックエンドの API サーバーとして Cloud Run を使用するアーキテクチャです。SPA は N

                                                                                  Cloud Run で作るサーバーレス アーキテクチャ 23 連発 - これのときはこう!
                                                                                • OIDCって何なんだー?から、実際に使うまで - BASEプロダクトチームブログ

                                                                                  ごあいさつ はじめましての人ははじめまして、こんにちは!BASE BANK Divisionのフロントエンドエンジニアのがっちゃん( @gatchan0807 )です。 今回は、ここ数ヶ月の間にOIDC(OpenID Connect)という技術を使った開発を複数行い、この技術の概観を理解することができたので、OIDCの技術概要に触れつつBASE BANKの中でどのように使ったのかをご紹介しようと思います。 OIDCとは何なのか このパートでは、まずOIDCという技術について概要を紹介します。いくつかのWebページに記載されていた内容を参考にしてまとめさせて頂いているので、記事の最後に参照元のリンクを記載しておきます。 また、OIDCをはじめとした認証・認可の仕組みには様々な用語があり、自分自身も「調べれば調べるほど知らない用語が増えて、どんどんわからなくなってきた…」という経験をしたので、

                                                                                    OIDCって何なんだー?から、実際に使うまで - BASEプロダクトチームブログ