可及的速やかにReactが絶滅しますように。 以下はFront-End Developer Handbook 2018の第三部、Front-end Developer Toolsからリンクされているツールと、その簡単な紹介です。 ドキュメントツール 開発者向けドキュメント、APIリファレンス Dash 200以上のAPIリファレンス、100以上のチートシートを一括ダウンロードできる。有料、Mac用。 DevDocs 200以上のライブラリをオンラインで検索できる。無料。 Velocity 中身はDashと同じ。有料、Windows用。 Zeal Windows、Linux、MacOS用各種揃っている無料のオフラインドキュメント。 チートシート devhints.io JavaScript、CSS、Go、vim等のショートカット、書式などチートシート。字が薄くて見辛い。 SEOツール Key
はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 本稿では、Webアプリケーション上で実装される「ログイン機能」の実装パターンをいくつか示し、その「仕様の中で起きうる脆弱性」とその対策について解説していきます。 「ログイン機能」はToB、ToC問わず多くのWebアプリケーションで実装されている機能で、XSSやSQL Injection、Session Fixationといったような典型的な脆弱性の観点については、なんらかの解説を見たことのある方も多いと思います。 しかし、「仕様の脆弱性」というのはあまり多く語られていない印象です。今回はそのようなタイプの脆弱性についての解説を行います。なお、IDaaSを用いずに自前でログイン機能を実装しているケースを複数パターン想定しています。 はじめに ログイン機能の仕様パターンとセキュリティ
コロナ禍 → リモートワークをきっかけに、趣味も仕事も楽しめる欲張りな家を建てた【エンジニア、家を建てる】 - MY HOME STORY │スーモカウンター注文住宅
職業柄、「よりよいもの」や「よりよい環境」を求める方が多いエンジニア。そんなエンジニアの「家づくり」にはきっと、さまざまなこだわりが詰め込まれているはず。 注文住宅を選んだエンジニアに登場いただく「エンジニア、家を建てる」。第2回はrela1470（渡辺 淳）さんに寄稿いただきました。 rela1470さんが注文住宅を購入したのは、新型コロナウイルスの感染拡大でリモートワークがメインとなったことがきっかけ。ワークスペースはもちろんのこと、サウナルームや防音室なども導入し「仕事」と「趣味」どちらもとことん楽しめる空間を手に入れました。 東京・表参道の株式会社KyashというFintech企業で、コーポレートエンジニアをしているrela1470と申します！ 2021年5月、茨城県取手市に念願の一戸建てを手に入れ、妻と2人で楽しく暮らしています。 業務内容にいわゆる情シス業が含まれているため少な
2020年のフロントエンドエンジニアの技術スタックの一例
年の瀬なので、私自身が今年利用した技術をベースに技術スタックをまとめてみようと思います。 とはいえ Web Standard といった広い対象から、フレームワークやライブラリまで、粒度の違うものを全て言及するのは無理があるというもの。特に強く言及できるものは個別で説明しつつ、最後に利用する機会がなかったものも最後に記載する形で。 以下常体。 追記: マイナー企業のようなので一応書いておきますが、筆者は本業ではLINE株式会社という組織でいわゆるエンジニアリングマネージャーと言われるような業務とその採用に関わる仕事をしています。 利用した技術一覧 HTML/CSS/JS みたいなことを書いてるとキリがないので、独断と偏見で区分けして適宜漉いています。特に利用する機会が多かったものは太字でピックアップ。 Frontend Language/Platform TypeScript JavaScr
仮想サーバ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の仮想化ハイパーバイザーとして使用されて
TL;DR 基本的には二重での暗号は不要 ただし、転送後も暗号化したまま使うなら、転送前から暗号化するのは良い ルールXを無邪気に追加して不整合のあるセキュリティルールを作ってはいけない はじめに 社内のセキュリティルールやスタンダードを決めるときに、HTTPSなのにVPN必須になってたりファイル暗号も必須になってたりするケースたまに見ます。今回は、それは実際に必要なことなのか？ セキュリティ的に有効なのか？ という点で考察をしていきたいと思います。 背景 二重三重に暗号化しても性能ペナルティが無いなら「なんとなく安全そうだから」でOKにしてしまいがちなのですが、これはよく考える必要があります。 というのも 「ルールXを追加することで既存のルールAと不整合が出る」 ってことは割とよくあるからです。具体的には「SCPのファイル転送は（SCPのセキュリティに不備があった時の）安全性のためにファ
不正アクセスによるIDとパスワードの漏洩を受けて、MD5によるハッシュ化について話題になっていました。システムを作る上で、パスワードの管理や認証はどう設計すべきかを考えるために、少し整理をしてみます。もし事実誤認があれば、どしどしご指摘ください。 == 2023/8/21追記 == この記事は、ハッシュの保存の仕方一つとっても、沢山の対策方法が必要であるということをお伝えするために記載しています。そして、これから紹介する手法を取れば安全とお勧めしている訳ではないので、その点をご留意いただければと思います。攻撃手法に応じての対応策の変遷を知っていただくことで、セキュリティ対策は一度行えば安全というものではないことを知って頂くキッカケになれば幸いです。 == 追記終わり == パスワードのハッシュ化 まず最初にパスワードの保存方法です。何も加工しないで平文で保存するのは駄目というのは、だいぶ認
おはようございます、ritou です。 qiita.com これの初日です。 なんの話か 皆さんは今まで、こんな記事を目にしたことがありませんか？ Cookie vs JWT 認証に JWT を利用するのってどうなの？ JWT をセッション管理に使うべきではない！ リンク貼るのは省略しますが、年に何度か見かける記事です。 個人的にこの話題の原点は最近 IDaaS(Identity as a Service) として注目を集めている Auth0 が Cookie vs Token とか言う比較記事を書いたことだと思っていますが、今探したところ記事は削除されたのか最近の記事にリダイレクトされてるようなのでもうよくわからん。 なのでそれはおいといて、この話題を扱う記事は クライアントでのセッション管理 : HTTP Cookie vs WebStorage(LocalStorage / Sess
自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく 分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。 だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。 戦術的DDD的観点での関心事の分離によるメリットとは コンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか？」を都度考えることを強制することができる。 境界がなければ意図しない密結合を生みやすくなってしまう。 もちろん、境界を超える
即戦力人材と企業をつなぐ転職サイト「ビズリーチ」は2009年にサービスを開始し、スカウト可能会員数は190万人以上（2023年1月末時点）のユーザーにご利用いただくサービスに成長しました。 今回、その「ビズリーチ」の認証基盤としてIDaaS（Identity as a Service）のOkta Customer Identity Cloud（Powered by Auth0）（以下Auth0という）の導入を行いました。 本記事では認証基盤を刷新するに至った背景とAuth0を用いて100万を超えるユーザーをログアウトさせることなく移行した方法についてご紹介いたします。 前提 本記事で得られる情報 本記事を読むことで以下のような情報を得ることができます。 IDaaSを選ぶ理由 IDaaSを用いて認証・認可を運用中のプロダクトに組み込んだ事例 運用中のプロダクトに組み込む際に発生しうる課題と対
ちなみに、IT業界全体のシェアとしてはMicrosoftのAzureの方がGCPを上回っていますが、Web業界においてIaaSにAzureを採用している企業さんは2019年時点ではまだまだ少ないので、現状ではとりあえずAzureへのキャッチアップは後回しにしておいて問題ないと思われます。 クラウドアーキテクチャ設計 前述したAWSやGCPの各種マネージドサービスを適切に組み合わせてアーキテクチャ設計を行い、それを構成図に落とし込める能力は必須となります。 いわゆる「アーキテクト」という職種の担当領域でもありますが、「サービスを安定稼働させたまま、バリューをユーザに迅速に届ける」ためには、自動化のしづらい構成が採用されてしまったり、無駄な機能が開発されてしまったり、アンマネージドなツールやサービスが使用されて管理工数が肥大化したりしないように、アーキテクチャ設計の段階からDevOpsエンジニ
【レポート】AWS における安全な Web アプリケーションの作り方 #AWS-55 #AWSSummit | DevelopersIO
この記事では、5月12日に行われた AWS Summit Online 2021 のオンラインセッション『AWS における安全な Web アプリケーションの作り方(AWS-55)』の模様をレポートします。 セッション概要 情報処理推進機構(IPA) の公開している「安全なウェブサイトの作り方」をはじめとしたセキュリティを考慮した安全なウェブアプリケーションの設計ガイドラインがいくつか知られています。本セッションでは、アプリケーション開発者向けにガイドラインに則ったアプリケーションを AWS 上でどのように実装するのかを AWS プラットフォームレイヤーとアプリケーションレイヤーのそれぞれの観点から項目ごとに解説し、アプリケーション導入前、または導入後のセキュリティ対策の指標となることを目指します。 登壇者 アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテク
Firebase Authentication 7つの落とし穴 - 脆弱性を生むIDaaSの不適切な利用 - Flatt Security Blog
はじめに こんにちは、株式会社 Flatt Security セキュリティエンジニアのぴざきゃっと (@pizzacat83) です。 認証機構を自作せずに導入できる Firebase Authentication は様々なアプリケーションにて利用されていますが、その特性を十分に理解せずに導入すると、実は不具合や脆弱性が生じることがあります。そこで本稿では Firebase Authentication を利用するうえで、注意しなければ不具合や脆弱性に繋がりうる 7 個の「落とし穴」について解説します。 はじめに IDaaS の利点と欠点 落とし穴 1. 自己サインアップ リスク 対策 不十分な対策 落とし穴 2. ユーザーが自身を削除できる 対策 落とし穴 3. 他人のメールアドレスを用いたユーザー登録 リスク リスク 3-1. メールアドレス誤入力によるユーザー乗っ取り リスク 3-2
Tailwind CSSで任意のメディアクエリを指定する Tailwind CSSでは簡単にメディアクエリの指定が可能です。 2023年11月 2日 00:40 カテゴリー CSS Tailwind CSSでdisabled Tailwind CSSでdisabled属性がついた要素に対してスタイルを当てたい場合には、disabled擬似クラスを利用して指定を行います。 2023年10月19日 15:32 カテゴリー CSS Vue.jsでコンポーネントの要素をpropsによって切り替える Vue.jsでボタンコンポーネントなどを作成する場合、ユースケースに応じてHTMLの実体をa要素とbutton要素と切り替えたいケースというのが発生します。 2023年9月15日 11:18 カテゴリー JavaScript Nuxt3でESLintの設定をする 案件でNuxt3のESLint設定をする
iCARE Developer Meetupは、月次で開催している株式会社iCAREが主催するエンジニア向けのLT勉強会です。18回目の今回は、Ruby on Railsをテーマに行いました。サーバーサイドエンジニアの越川氏からはToken認証機能について。 Rails APIモードで開発するときの認証用のトークンはどこに保存すればいいの問題 越川佳祐氏：私からは、「Rails APIモードにおけるToken認証機能について」というテーマでLT（ライトニングトーク）をしようと思っていたんですが、スライドを作っていて「あれ、これ別にRailsだけの話じゃなくない？」と思ってしまいました。みなさんの中にも、そう思う方がいるかもしれないんですが、もうこれで作っちゃったのでご了承ください。 私は株式会社iCAREで、サーバーサイドエンジニアをしている、越川と申します。Twitterは@kossy0
AWSマルチアカウントにおけるIAMユーザー設計戦略を考えてみる - How elegant the tech world is...!
はじめに 2020年3月以来の投稿になりますが、「AWS案件に携わる中で、いろいろと貯まった知見を世のエンジニアの皆さんと共有したいな..」という思いに突然駆られ、本稿ではAWSマルチアカウントにおけるIAMユーザ設計の戦略をご紹介します。 ビジネスの要件・制約等により、取り得る設計は様々ですが、一つのベストプラクティス例としてご参考になればと思います。 IAMポリシーに関する基本方針 カスタマー管理ポリシーの利用 AWS利用において、避けては通れないIAM設計。 AWSでは、AWSアカウント（ルートユーザー）の通常利用は推奨しておらず、 AWSアカウント作成後は速やかにIAMユーザーを作成される方も多いのではないでしょうか。 AWS アカウントのルートユーザー 認証情報を使用して AWS にアクセスしないでください。また、認証情報を他のだれにも譲渡しないでください。代わりに、AWS アカ
Hello,World! gonowayです。 弊社がご支援するお客様とお話するなかで、多要素認証のためにIDaaSが提供しているアプリケーション（以降、認証アプリ）を私物モバイル端末にいれていいのか？という疑問に、わたしたちが普段お客様にご案内していることをざっくりまとめてみました。 3行まとめ 現代では外部の不正ログインから守るために多要素認証が必須になってきている。 多要素認証の実現のため、会社モバイル端末であれ私物モバイル端末であれ認証アプリはインストールしてほしい。 私物モバイル端末にインストールしてもらう場合、エンドユーザーへの説明を行うことが必要。また、ガラケーしか持っていないような例外措置への対処を考えることも必要。 前提 認証要素について 認証要素は下記の3種類です。NIST SP800-63を参考にしています。 記憶によるもの：記憶(Something you know
不正送金やアカウントの乗っ取りなど、パスワードが原因の事件が後を絶ちません。高齢者など、IT リテラシの低い人でも簡単かつ安全に自分のオンラインアカウントを管理できる世界が理想ですが、まずはパスワードの不要な世界を実現するのが先決であることは、これまでのインターネットの歴史で証明されたと言えるでしょう。そして、ここに来てパスワード不要なログインを実現する技術として注目されているのが FIDO (= Fast IDentity Online, 「ファイド」) です。そしてその FIDO をブラウザから利用できるようにするのが WebAuthn (= Web Authentication、「ウェブオースン」)。報道内容などからこれらは指紋認証を実現するもの、と思っている人もいらっしゃるかもしれませんが、実際にはちょっと違います。 WebAuthn に関しては、すでに数多くの記事が出ていますので
AWS 診断を事例としたクラウドセキュリティ。サーバーレス環境の不備や見落としがちな Cognito の穴による危険性 - Flatt Security Blog
こんにちは。本ブログに初めて記事を書く、株式会社 Flatt Security セキュリティエンジニアの Azara(@a_zara_n)です。普段は Web やプラットフォームの診断やクラウド周りの調査、Twitter ではご飯の画像を流す仕事をしています。よろしくお願いします。 クラウドサービスが発展し続ける今日この頃、多くの企業がパブリッククラウドやプライベートクラウドなどを駆使し顧客へサービス提供しているのを目にします。そのような中で、サービスが利用するクラウドにおいて設定不備や意図しない入力、構成の不備により顧客情報や IAM をはじめとする認証情報が脅かされるケースが多々あります。 本記事では、そのような脅威の一例をもとにクラウドサービスをより堅牢で安全に利用する一助になればと、攻撃手法や対策などについて解説をしていきます。 また、私の所属する 株式会社 Flatt Secur
ECサイトやSaaSのアカウントを作るため、入力フォームに全角で住所を打ち込み。番地や郵便番号などの数字は半角で書き、情報を登録しようとしたら「この情報は半角では入力できません。全角で入力してください」。よく見るとページ内に「番地は全角で入力してください」という注意書きがあったので、再度打ち直し──入力フォームを使ったことがある人なら、多くの人がこんな面倒な経験を味わっているのではないだろうか。 こういった仕様は巷（ちまた）にあふれており、ネットで「全角・半角問題」などと呼ばれている。ユーザーに不便を強いているにもかかわらず、このような入力フォームはなぜなくならないのか。 この課題のソリューションとして、ユーザーが入力フォームに打ち込んだ文を自動で半角・全角に統一するなどの機能を持つJavaScriptライブラリ「InputManJS」を提供するグレープシティ（仙台市）の若生尚徳さん（ツー
Kyashでは9月からIDaaSであるOneLoginを導入しました。 導入から3ヶ月が経過し、現時点でほぼすべての社内認証をOneLoginに統一することが出来ました! 今回は、なぜOneLoginにしたのか、使い勝手等を含めお伝えできればと思います。 すごくヨイショしている記事になってしまったんですが、お金はもらってません!!!!!笑 www.onelogin.com 公式HPにも取り上げて頂き、ありがとうございます! 実は前職でもかなり使い込んでおり、OneLoginは思い入れのあるプロダクトです。 www.pentio.com 今回の導入に関しても、OneLogin 日本代表の福見さんと代理店であるペンティオさんにかなりのお力添えを頂きました。ありがとうございます! Kyash Advent Calendar 2019 day11 ということでKyash Advent Calend
こんにちは、2019年7月よりトレタにJOINした @aibou です。 本記事はトレタ Advent Calendar 2019の16日目の記事です。 趣味はNFL観戦とボルダリングです。NFLは今年11月にマイナス気温の屋外で現地観戦してきました。 最近リードクライミングの講習を受けまして、ガシガシと岩を登っております。 さて、今回はAWSアカウントとAWS SSOのお話をしようと思います。 既に社内エンジニアへの共有や社内WikiにAWS SSOの利用マニュアルを残していますが、経緯や変遷について記載していないので、トレタ社員の方にも読み物として読んでいただければなと思っています。 免責事項 本記事を参考に実施したことで発生した金銭・セキュリティ等あらゆる問題について責任を負いかねますので、自己責任のもと実施していただくよう、よろしくお願いいたします。 また、誤り等あればはてブ等でご
仕様起因の脆弱性を防ぐ！開発者向けセキュリティチェックシート(Markdown)を公開しました - Flatt Security Blog
はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 これまで弊社ブログでは様々な「仕様とセキュリティ観点の解説記事」を発表してきました。今回はいままでの記事を改めて紹介しつつ、読者の皆様が開発中のサービスでセルフチェックを行えるよう「仕様とセキュリティ観点チェックリスト」を作成しました。ご活用いただけると幸いです。 ダウンロードは下記のGitHubリンクよりどうぞ。 また、株式会社Flatt Securityではお客様のプロダクトに脆弱性がないか専門のセキュリティエンジニアが調査するセキュリティ診断サービスを提供しています。料金に関する資料を配布中ですので、ご興味のある方は是非ご覧ください。 はじめに アプリケーションの仕様起因の脆弱性とは アプリケーションの仕様起因の脆弱性を防ぐために 仕様の脆弱性によく見られる共通点 1. ク
Google Cloud Identity Services昨日開催された「リーグオブ情シス #7」でも紹介されていた、Google Cloud Identity Freeを試してみます。 Google Cloud Identity Freeとはデバイス管理やディレクトリ管理、SAMLを利用したSSOなどGoogle Cloud Identityのほとんどの機能を無料で利用できるライセンス体系です。 閲覧だけに限って言えば、Google Driveの共有ドライブも利用することが可能です。 作成できるユーザー数は「50」までに制限され、プロビジョニングなどはできませんが、ユーザーの組織管理という観点においてはほとんどのことを十分にこなすことが可能です。 Google Workspaceを利用している場合は、同じ組織内にユーザーを共存させることも可能なので、小さな組織でパート・アルバイトの方な
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利用部
Firebase AuthなどJavaScriptでAPIセッション用のトークンを得ることについて - Qiita
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう （※ こちらの参照記事の内容自体に不備があるとか甘いとか指摘するものではないんですが、勝手に枕として使わせてもらいます） 上記記事は、Firebase Authenticationが提供するJavaScript APIを使ってJWTのトークンを取得し、自前のサーバにHTTPのヘッダで送りつけて検証をさせることで、認証の仕組みをセキュアかつかんたんに実現しよう、という内容です。 このようにJavaScriptのAPIでトークンを発行して自前バックエンドのAPI認証につかう方法はAuth0のSDKなどでも行われていますので、IDaaSをつかってSPAを開発する場合には一般的なのかもしれません。 話は変わりますが、SPAの開発に携わっている方は「localStorageにはセッション用のトー
今日(2022/07/07)は弊社、Classmethodの創立記念日ということで、 AWSのマルチアカウント戦略で思ったこと をそのまま書き殴ってみました。 共感するところや他に苦労しているところ思いついた方は Twitter 等で共有いただけると嬉しいです！ 思いつく限り書いた結果の目次がこちらです。 「アカウントをどう分割するのか」問題 「AWS Control Tower を活用したほうがいいのか」問題 「ユーザー管理どうするのか」問題 「最小権限とは言っても」問題 「管理アカウントでの作業が怖い」問題 「OU/SCP周りの更新が怖い」問題 「セキュリティをどう向上するか」問題 「アカウント数のスケールにどう対応するのか」問題 「ベースラインの構築/管理をどうするか」問題 「ログ集約するのか/しないのか」問題 「どのアカウントかぱっと見て分からない」問題 「Security Hub
【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のセキュアな利用
【v2対応】Nuxt.jsとFirebaseを組み合わせて爆速でWebアプリケーションを構築する - Qiita
Firebase Advent Calendar 2017 21日目の記事です。 フリーランスでフロントエンドを中心にエンジニアをやっているpotato4dです。 普段はVue.jsを中心に、案件を進めたりコミュニティに関わったりしていますが、今回はそんなVue界隈で今アツいフレームワークであるNuxt.jsとFirebaseを組み合わせて、SPA + SSRにAuthと Firestore を組み合わせたアプリケーションを高速で作る方法を、サンプルとあわせてご紹介します。 2019/10/16 追記 このサンプルは Firestore が存在しない Nuxt v1.x + RTDB 時代のコードを愚直に移行している ので全体的に資料が古くなっています。 インフラ構成については順次更新していますが、特にデータストア操作周りについては できるだけ参考にしないでください。 2019/07/02
はじめに みなさんはじめまして。BASEでエンジニアをしております田村 ( taiyou )です。 先日、BASEではショップオーナー向けのコミュニティサイト「BASE Street」にログインするための機能としてSSOログイン機能をリリースしました。 SSOログインを実現するための認証方式はいくつかあるのですが、弊社ではSAML認証方式を用いて実現しました。 そのため、この記事ではSAML認証機構のIdPとしてOSSを使わずにSAML認証機能を実装する方法を紹介します。 前回のテックブログで、このSSOログイン機能のフロント側を開発したPJメンバーの若菜が「サーバーサイドエンジニアがフロントエンドに挑戦して最高の経験になった話」を執筆したのでこちらも見てみてください！ SAML認証機能を提供しているOSSには、Keycloakなどがありますが、BASEでは以下の理由により自前実装すること
Google Workspaceのプライマリドメイン変更を実施しました - Pepabo Tech Portal
こんにちは、ペパボのCorporate Engineering Group（以下CEG）でソフトウェアエンジニアをしている加治です。 CEGでは、主にペパボ社内で利用されている社内向けサービスの開発・運用・保守を行っています。運用・保守を行っているサービスの中にはSaaSも含まれています。そのSaaSの一つであり、ペパボでメインで使用されているオフィススイートであるGoogle Workspaceのプライマリドメインを変更したお話をします。 最初に、このお話のターゲットを明確にしておこうと思います。 これからプライマリドメインを変更したい情シス、コーポレートエンジニアなどの担当者 プライマリドメインを変更したことがあり、ペパボではどうだったのかな〜と気になった人 Google Workspaceの運用をしていて、プライマリドメインが事実上のメインのドメインと異なるときの影響を知っておきたい
接続元のネットワークやデバイスを問わず常にアクセスを精査し、適切に認証・認可をするセキュリティーモデル「ゼロトラストアーキテクチャー（ゼロトラスト）」が注目を集める。 コロナ禍でテレワークが普及し、社外からインターネット経由でクラウドサービスに直接アクセスする企業が続出した。それに伴い、ファイアウオールで社内外のネットワークを区切り、社内は安全なものとみなす「境界型セキュリティー」ではデータを守り切れないケースが増え、ゼロトラストの注目度はさらに高まっている。 だが何か1つ製品を導入すればよいというものではない。既存の技術で完全なゼロトラストを実現するのは困難ともいわれ、雲をつかむような話に苦戦する企業は多いようだ。 そんな中、経済産業省は2021年5月12日に「DXオフィス関連プロジェクト管理業務等の効率化に関するデジタルツールの導入実証・調査事業」の報告書をソフトウエア開発プラットフォ
Amazon の 2段階認証 突破の噂についての仮説 と 2段階認証で意識すること【2FA/2SV/MFA】 - Qiita
Amazon の 2段階認証(2SV)が突破された？ Amazon の 2段階認証(2SV) が突破されたのではないかという件が話題になっています。 私もこれについてはとても気になっており、できるだけ早く真相が解明されることを願っています。 そこで、ふと疑問に感じたことが、2SV は何をどの程度防いでくれるのかということです。 ここでは、Amazon を例に、いろんなことを考えていきたいと思います。 フィッシングの前には無力 まず、2SVの突破と言っても様々な手口があります。 徳丸先生の動画が示す通り、中継型フィッシングであれば、自ら正しい認証情報を入力することになるので、2SVを設定していようがいまいが突破されてしまいます。 フィッシングではなく、かつ、TOTPでも突破されたケースも 今回の被害者には、中間者攻撃やフィッシングを受ける状態になかったと仰っている方がいました。 なので、何か
次の設計原則に従って、アプリケーションのスケーラビリティを上げて、回復力や管理しやすさを強化します。 自動修復機能を設計します 。 分散システムでは、障害が発生します。 障害の発生に備えてアプリケーションの自動修復機能を設計します。 すべての要素を冗長にします 。 単一障害点をなくすようにアプリケーションに冗長性を組み込みます。 調整を最小限に抑えます 。 アプリケーション サービス間の調整を最小限に抑えてスケーラビリティを実現します。 スケール アウトするように設計します 。需要に応じて新規インスタンスを追加または削除し、水平方向に拡張できるようにアプリケーションを設計します。 制限に対処するようにパーティション化します 。 パーティション分割を使用して、データベース、ネットワーク、コンピューティングの制限に対処します。 操作に合わせて設計します 。 運用チームが必要なツールを得られるよ
無料で使える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アカウントではユーザーアカ
前置き この記事で紹介するアーキテクチャはあくまで机上論であり、筆者が実際にこれらのアーキテクチャでサービスを運用したことがあるわけではありません。 そのため、考慮漏れ等あるかもしれません。その際はご指摘いただけますと幸いです。 モチベーション 個人開発でアプリケーションを作って運用したい！ お金は極力かけたくない！ けどいい感じのツールを組み合わせてクールなアーキテクチャにしたい！ 対象とするアプリケーションの概要 ブラウザで動くウェブアプリケーション 認証機能を持つ DBはNoSQLではなくRDB アプリケーション本体とは別に管理画面アプリケーションが必要 以上を前提として考えました。 ぼくのかんがえたさいきょうあーきてくちゃ こちらです。 コンポーネントごとに解説させてください。 フロントサーバー Next.js on Vercelです。 こちらはもはや説明不要の王道構成かと思います
OAuthの言葉周りを整理する
OAuthの仕組みとToken認証周りの言葉はいつまで経ってもはっきり理解できないものの一つでした。 しかし最近ようやく理解できるようになってきたのでとりあえずそれぞれの言葉の指すものや定義をここで整理してみようと思います。 リフレッシュトークン リフレッシュトークンとは アクセストークンの有効期限が切れたときに、認可サーバーにアクセストークンの更新リクエスト認証をするためのトークン。 OAuth自体はリフレッシュトークンがなくとも実装できるが、リフレッシュトークンはOAuthをより便利にするためのもの。 一般的に有効期限は長い。 ないとどうなるのか アクセストークンの期限が切れたらその度にSNS認証のあのログイン画面に飛ばされてメアドとパスワードの入力が必要になる。 セキュリティに関すること 有効期限が長くても安全性に問題がないと考えられる理由としては、アクセストークンの期限切れ時にしか
Google Cloud の IDaaS「Identity Platform」で作る、さまざまな認証パターン
Identity Platform を使うと、さまざまな認証パターンが構築できる！ この記事は2023年10月6日に行われたナレッジワークさん主催のイベント「Encraft #7 AppDev with Google Cloud」で発表したセッションの解説記事です。現地でご参加いただいた皆さん、オンラインでご視聴いただいた皆さん、ありがとうございました！ 私のセッションでは Identity Platform を使ったさまざまな認証パターンについてご紹介しました。セッション後、いくつかのご質問や「こんなパターンもあるよ！」というコメントもいただきました(ありがとうございます！)。この記事では、セッション内でご紹介した内容に加え、別解、または発展系とも言えるいくつかのパターンについてもご紹介します。 Identity Platform とは まずはこの記事でメインで扱う Identity P
Azure Active Directory (AzureAD)をご存知でしょうか？ Azure ADについて 今まで企業の端末やユーザ管理をするとき使われてきた、Windows Actice Directoryのようなものですが、根本的な設計は全く異なります。SAML認証に対応していたりと、いわゆるIDaaSのようなもので、組織がクラウドサービスを利用する際のID基盤として使われています。 Microsoft Azureや組織向けOffice 365、Microsoft 365を利用している方は、ほぼ自動的にAzureADのテナントで管理されるユーザとして利用していると思います。 AzureAD知ってるよという方、会社や学校のアカウントの個人IDもAzureADを利用して払い出されている方も多いのではないでしょうか？いろんな便利なSaaSが増えてきたし、1つのアカウントで各サービスが使え
「なぜクラウドなんだ」「今までのやり方を変えないで」――反発乗り越えAWSなど導入 京王バスを変えた男の交渉術
「なぜクラウドなんだ」「今までのやり方を変えないで」――反発乗り越えAWSなど導入 京王バスを変えた男の交渉術（1/2 ページ） 「クラウド導入を試みた当初は、『なぜクラウドを使うのか』『今までのやり方を変える意味が分からない』などと、周囲からさまざまな反発に遭いました」――。京王電鉄の虻川勝彦氏（経営統括本部 デジタル戦略推進部長）は、12月10日に開催されたシステム担当者向けイベント「NetApp INSIGHT 2019 TOKYO」でこう語った。 【更新履歴：2019年12月12日 午後10時45分更新 追加の取材と事実確認に基づき、本文の一部を変更しました】 虻川氏は、グループ会社の京王電鉄バス（以下、京王バス）に出向していた2011年から、システム刷新プロジェクトの責任者としてクラウド導入を推進。グループウェアに「Office 365」、アプリ開発基盤に「kintone」を導入
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2018年のフロントエンドエンジニアならこの程度は知ってて当然だよな？ - Qiita
Webサービスにおけるログイン機能の仕様とセキュリティ観点 - Flatt Security Blog
え、HTTPSの転送なのにファイルも暗号化するんですか？？？
何故パスワードをハッシュ化して保存するだけでは駄目なのか？ - NRIネットコムBlog
Webアプリケーションのセッション管理にJWT導入を検討する際の考え方 - r-weblife
認証と認可と課金とコアドメインを分離したシステムは勝てるという話 - まっちゅーのチラ裏
100万ユーザーをログアウトさせずに新認証基盤に移行した話
2019年のDevOps/MLOpsエンジニアの標準的スキルセット - Qiita
[to-R]JavaScriptやSEO対策、CSS、Movable Typeなどの情報を発信
認証用トークン保存先の第4選択肢としての「Auth0」
多要素認証を私物スマホでやっていいのか問題
パスワードの不要な世界はいかにして実現されるのか - FIDO2 と WebAuthn の基本を知る
不便で仕方ない「住所入力の全角・半角問題」はなぜなくならないのか 専門家に原因を聞く
KyashがOneLoginを選んだ理由 - rela1470のブログ
入社後にAWSアカウントの整理とAWS SSOを導入した話 - トレタ開発者ブログ
完全無料のIDaaS！？Google Cloud Identity Freeを試してみる
AWSのマルチアカウント戦略が難しい！ | DevelopersIO
IdPとしてSAML認証機能を自前実装した - BASEプロダクトチームブログ
経産省がゼロトラストの概念取り入れた業務環境、「イケてる」作りに驚いた
Azure アプリケーションの設計原則 | Microsoft Docs
ぼくのかんがえたさいきょうの個人開発あーきてくちゃ
【注意喚起】AzureADの設定適切ですか？意図しない情報公開について。 - Qiita