NET マイクロサービスおよび Web アプリケーションをセキュリティで保護する
マイクロサービスと Web アプリケーションのセキュリティには多くの側面があり、そのトピックは容易にこの記事のような内容の書籍数冊分になってしまいます。 そのためこのセクションでは、認証、承認、およびアプリケーション シークレットに焦点を当てます。 .NET マイクロサービスおよび Web アプリケーションに認証を実装する サービスによって発行されるリソースや API を特定の信頼されたユーザーやクライアントに制限しなければならないことはよくあります。 このような API レベルの信頼の決定を行うための最初の手順は、認証です。 認証は、ユーザーの ID を確実に検証するプロセスです。 マイクロサービスのシナリオでは、通常、認証は一元的に処理されます。 API ゲートウェイを使用している場合、図 9-1 に示すように、このゲートウェイから認証することができます。 このアプローチを使用する場合
マイクロサービスの認証・認可とJWT / Authentication and Authorization in Microservices and JWT
OCHaCafe Season4 #4の資料です． デモのソースコード等はこちらをご参照ください．
"JWT=ステートレス"から一歩踏み出すための考え方
おはようございます、ritouです。 この話に乗っかっていきます。 3行で ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど) JWTは単純なフォーマットなので、ステートレスなセッション管理においてログアウトしたときに文字列自体を無効化できない件は独自エンコード方式(一般的にフレームワークのCookieストアと呼ばれているもの)でも起こり得る 「セッションID vs JWTで内包」 以外にも 「セッションIDをJWTに内包」もあり得る。既存の機能を残しつつ「JWTで武装」する選択肢も考えてみてはどうか。 ステートレスなセッション管理でログアウトの際に文字列自体を無効化できない問題 これは前から言われていますし、駆け出し何とか勢のQiita記事に書かれるぐらいには一般的です。 2
AWS cognito を使って React SPA に認証機能を導入してみた
今時の認証って🧐 現代はもう認証機能は自分で実装する時代では無さそうです。 この、「どのアプリでも一般的に使われているけど本質的な価値になっていない」類の作業を、かの AWS センセーは 「付加価値を生み出さない重労働」 と定義しました。 これらをなるべく削減して、エンジニアが本質的な顧客価値に直結する作業に注力できるようにするのというのがトレンドです。 せっかくReact で初めてのSPAを作ったので、ついでに前から気になっていた AWS cognito を使って認証機能を付けてみました。 ざっくりとした導入だけですが、基本的な使い方だけなら非常に簡単かつセキュアに実装できるのでは無いかと思います！！ 以前作った SPA については記事にしています。 こちら 。 Rails API でバックエンドを実装した React SPA についてイメージを掴めるような内容になっていると思いますの
ASP.NET Core のための gRPC での認証と承認
サンプル コードを表示またはダウンロードする (ダウンロード方法) gRPC サービスを呼び出しているユーザーを認証する gRPC を ASP.NET Core 認証と共に使用して、ユーザーを各呼び出しに関連付けることができます。 以下に、gRPC と ASP.NET Core 認証を使用する Program.cs の例を示します。 app.UseRouting(); app.UseAuthentication(); app.UseAuthorization(); app.MapGrpcService<GreeterService>(); 呼び出し時にアプリによって使用される認証メカニズムは、構成する必要があります。 認証の構成は、Program.cs に追加され、アプリで使用される認証メカニズムによって異なるものとなります。 認証が設定されると、ServerCallContext を介し
Microservices における認証と認可の設計パターン
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
マイクロサービスで管理画面が乱立する問題と対策
こんにちは、qsona (twitter) です。 マイクロサービスアーキテクチャを指向するとき、(主に社内向け)管理画面をそのままサービスごとに作っていくと、マイクロサービスの数だけ管理画面が乱立するという課題があります。FiNC においては、それにより実際に以下のような問題が発生しました。 ユーザの追加/削除や権限管理がとても大変ユーザ(CS対応者)がどこの管理画面を使えばわかりにくい本記事では、 FiNC においてこれらの問題に対してどう対処してきたか、歴史とともに紹介します。 tl;dr各マイクロサービスで管理画面を作ること自体はよい。統一管理画面は開発のコストがかかりワークしなかった認証を中央管理にする権限管理は各サービス固有のドメイン知識だが、中央で一覧/変更できる状態になっていると便利マイクロサービスの横断的関心事への対処は、「標準」を意識する黎明期から、問題が起こるまでFi
マイクロサービスにおける内部通信の認証について
"Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~"の発表資料です。 https://connpass.com/event/142624/
メルペイのマイクロサービスアーキテクチャの裏側と、不整合を防ぐための工夫
2019年7月24日、ヤフー株式会社が主催するサーバーサイドエンジニア向けの勉強会「Bonfire Backend #3」が開催されました。第3回となる今回のテーマは「モバイル決済の裏側」。急速に成長するモバイル決済分野でサービスを展開する企業が一堂に会し、自社サービスの仕組みや技術スタックなど、知られざる裏側を語ります。プレゼンテーション「静的MPM決済を支える技術 」に登壇したのは、株式会社メルペイのsusho氏。今年の6月にサービスが開始したばかりのメルペイのサーバーサイドの特徴と工夫について語ります。 静的MPM決済を支える技術 susho氏：こんばんは。「静的MPM決済を支える技術」ということでsushoが発表させていただきます。 最初に自己紹介です。 社内ではsushoと呼ばれているので、ここでもそうさせていただいております。Twitterは@susho0220でやっています。
開発者はコアな機能の実装に集中できる！ Auth0が提供する認証・認可の最適解【デブサミ2019夏】
認証・認可はどんな種類のアプリケーションにも求められる機能だ。一方で、技術仕様が複雑で実装が困難な領域でもある。「仕様の調査に膨大な時間がかかった」「認証の実装方法に不備があり、アプリケーションに脆弱性を作ってしまった」といった経験を持つエンジニアは少なくないだろう。そうした課題を解決してくれるのが、Auth0株式会社が提供する認証・認可のプラットフォームである。多種多様な機能を有する同社のライブラリは、わずか数行のコードを記述するだけで利用可能だというから驚きだ。同社ソリューションズエンジニアの山口央氏が、Auth0のサービスを用いて認証・認可の課題を解決する方法を解説した。 講演資料：ソフトウェア開発における認証・認可の位置付けと課題、現実解を探るアプローチ Auth0株式会社 ソリューションズエンジニア 山口央氏 認証・認可を外部サービスでまかなうことの利点 現代は、数多くのアプリケ
OAuth 2.0 クライアント認証 - Qiita
はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。
Blazor+identity
Mental health has been in the news quite a bit lately. Dozens of U.S. states are currently suing Meta for contributing to the youth mental health crisis by inserting addictive features into their products, while the U.S. Surgeon General is touring the nation to bring awareness to the growing epidemic of loneliness and isolation. The country has endured periods of low national morale, such as in th
モダンBFFを活用した既存APIサーバーの再構築 - クックパッド開発者ブログ
技術部の青木峰郎です。 去年までは主にデータ分析システムの構築を担当していましたが、 最近はなぜかレシピサービスのサービス開発をやっています。 今日は、そのサービス開発をする過程で導入したBFF（Backends for Frontends）であるOrchaについて、 導入の動機と実装の詳細をお話しします。 Orcha導入にいたる経緯 まずはOrcha導入までの経緯、動機からお話ししましょう。 最初のきっかけは、わたしが去年から参加しているブックマークのようなサービスの開発プロジェクトでした。 このプロジェクトの実装のために新しいmicroserviceを追加することになったのですが、 そのときにいくつかの要望（制約）がありました。 1つめは、撤退するとなったときに、すぐに、きれいに撤退できること。 2つめが、スマホアプリからのAPI呼び出し回数はできるだけ増やしたくない、という要望です。
認証と認可 - Qiita
行動やリソースの使用を許可すること。 「伺っております。奥へどうぞ」 もともと 認可 = 認証 で長いこと来ていた。 認証 = 認可 の時代 認可は「玄関を開けて中へ入る」ことに例えることができる。 「鍵」を持っている人間は「玄関を開けて中へ入る」ことができる。これは明らかに行動の許可。なので、認可だ。 (この「鍵」とはつまりIDとパスワード、またはそれに類するもろもろのことだ) 周囲の知らない人間からすれば、家の鍵を開けて入る人間はまあその家の人間だろう、としか思われない。これが 認可 = 認証 の時代である。 しかし、様々なサービスが普及するとこの「鍵」が増えすぎるという事態が発生した。鍵束がジャラジャラして邪魔になったようなものである。 単に邪魔なだけならまだしも、管理が行き届かなくなるのは自明である。 また横着して同じ「鍵」を使い回すことも行われるようになった。これはセキュリティ上
よくわかる認証と認可 | DevelopersIO
よく訓練されたアップル信者、都元です。「認証 認可」でググると保育園の話が山程出て来ます。が、今日は保育園の話ではありません。そちらを期待した方はごめんなさい。こちらからお帰りください。 さて、先日のDevelopers.IO 2016において、マイクロWebアプリケーションというテーマでお話させて頂きました。一言で言うと OAuth 2.0 と OpenID Connect 1.0 のお話だったのですが、これらを理解するにあたっては「認証」と「認可」をはっきりと別のものとしてクッキリと認識する必要があります。 まず、ざっくりとした理解 認証と認可は密接に絡み合っている一方で全く別の概念です。正直、理解は簡単ではないと思います。 まず「認証」は英語では Authentication と言います。長いので略して AuthN と書いたりすることもあります。意味としては 通信の相手が誰（何）であ
Kubernetes上にAPI Gatewayを立て、経路の暗号化と認証認可を行わせる - Qiita
はじめに 皆さんKubernetesを使っていますか？ 宣言的にコンテナベースのインフラを構成できるKubernetesは便利ですが、Internetへ何らかのサービスを公開する場合には必須となる「公開サービスの経路暗号化」や「公開サービスの認証認可」は、残念ながらKubernetes自体には備わっていません（Kubernetes自体には認証認可機構が有りますし、Kubernetes上に起動されるサービスのアレコレはKubernetesの範疇外なので、当たり前といえば当たり前ですが）。 Kubernetesのパッケージマネージャ的な位置づけであるHelmには、nginxでL7ロードバランサーを構成するnginx-ingressが公開されています。このnginx-ingressは非常に高機能で、パスベースのルーティングもできますしTLSの終端やBASIC認証等をさせることもできます。上手くハ
Kubernetesのユーザー管理と認証・権限確認機構を理解しよう | さくらのナレッジ
Kubernetesはさまざまな環境で利用され、かつ不特定多数がクラスタにアクセスできることを前提に構築されており、そのため非常に柔軟なユーザー認証機構やユーザーの権限を管理する機能が組み込まれている。本記事ではこれらの認証や権限確認機構がどのように働くのかや、その仕組みについて解説する。 Kubernetesにおける認証の必要性 Kubernetesはさまざまな企業・組織が参加するオープンな組織「Cloud Native Computing Foundation(CNCF)」によって開発が進められているが、元々はGoogleによってその開発がスタートしたプロジェクトであり、同社の持つコンテナクラスタ管理技術を元にしている。そのため、Kubernetesは当初から不特定多数がアクセスできるパブリッククラウドでの利用が想定されており、そういった環境でもセキュアかつ柔軟に利用できるよう設計され
AWS Dev Day Tokyo 2018 で「マイクロサービス時代の認証と認可」の話をしてきた #AWSDevDay | DevelopersIO
緊張すると声がヤムチャになる都元です。このセッションの自己紹介でアムロ・レイとか言って盛大にスベったので切り替えていきます！ さて、1週間の時間が経ってしまいましたが、去る 11/2 (金) に目黒セントラルスクエアにおいて「マイクロサービス時代の認証と認可」と題しましてお話をさせていただきました。 スライド 認証と認可の基礎知識 繰り返しになりますので、過去エントリーよくわかる認証と認可 ｜ DevelopersIO を参照してください。 また、Web API のアクセス制御としては、だいたい次の4つくらいが頭に浮かぶと思います。 Basic 認証 Digest 認証 リクエスト署名 OAuth 2.0 この辺りは Spring Day 2016 - Web API アクセス制御の最適解でお話したことがありますので、こちらも併せてご覧ください。 Coffee break: 都元、日頃のお
OAuth 2.0 / OIDC 実装の新アーキテクチャー - Qiita
1.『On-Premises』パターンは、自分でマシンを用意し、そこに認可サーバーのソフトウェアをインストールして運用する方法です。 2.『Hosted Server』パターンは、マシンの物理的な運用はクラウドサービスにまかせ、そのマシン上に認可サーバーのソフトウェアをインストールして運用する方法です。 例えば AWS の EC2 インスタンスに OpenAM をインストールして運用する場合、このパターンに該当します。 3.『Hosted Service』パターンは、認可サーバー自体がクラウドサービスとして提供されるパターンです。 Okta や Auth0 がこのパターンに該当します。 4.『Semi-Hosted Service』パターンは、認可サーバーの主要機能を提供するサーバーが存在するものの、一部をローカルで実装するというパターンです。 Richer 氏が明示的に言及しているように
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Streaming and Authentication in gRPC (ASP.Net Core) - .Net Core Central