こんにちは、Azure Identity サポートチームの鈴木です。 本記事は Your Pa$$word doesn’t matter を意訳したものになります。ご不明点等ございましたらご連絡ください。 セキュリティに関して組織の方針を決定できる方との会話の中で 「これまでに漏洩したことがあるパスワードは絶対に再度使用するな」「長いパスワードを使用したほうがいい」「パスワードよりも長いパスフレーズを使えばいい」などなどの話題がでます。実はこれらは、これまでの研究結果と異なっており、マイクロソフトが毎日何億ものパスワードベースの攻撃を防いでいる状況から見ますと正しくありません。多要素認証 (MFA) や脅威の検出の仕組みなど本当に価値のあるものにではなく、パスワード規則に着目しても、気晴らし程度の効果しかありません。 ここでは、パスワードの構成や長さに関しては（ほとんど）意味がないというこ
「安全意識は事件をきっかけに大きく変化する」といわれています。7payにまつわるインシデントは、ITセキュリティやデジタルに強い人以外にも「二段階認証」というキーワードを浸透させました。ITセキュリティ業界にとって、象徴的な事件になったといえるでしょう。 本連載は7年前、「ITなんかよく分からない、デジタルなんて関係ない」という方に向けて、それでも知ってもらいたいITの基本を伝えるためにスタートしました。連載当初、二要素認証について書きましょうと編集部に提案し、「対象読者には難しすぎる」とボツにされたのを覚えています。 しかし現在、二段階認証は、銀行やキャッシュレス決済システムを中心にさまざまなサービスで利用されています。既に身近なサービスで導入されていたため、7pay事件で初めて二段階認証という言葉を知って、すぐに「ああ、登録した電話番号に数字が送られてくるあれか」とピンと来た方もいたの
最近Web APIの認可について思いを馳せる機会があったのだけど、どの方法で認可を実装するのがスタンダードなのか、そもそもそんなものは最初からないのか、よく分からなくなったので自分なりの考えをまとめることにした。 ファーストパーティのアプリが使うWeb API（プライベートなWeb API）の場合はセッションを使うケースもあるだろうが、セッションを使うケースでは悩むことも少なかったので、ここではアクセストークンを用いた認可にフォーカスして考えてみたい。ケースとしてはユーザー毎にアクセストークンが発行され、Browser-BasedアプリやNativeアプリからWeb APIが叩かれることを想定している。 追記 2019/03/04 認証や認可周りについてよく拝見させてもらっている方にブログで言及していただきました。合わせて読むことをお勧めします。 ritou.hatenablog.com
サーバレスアーキテクチャで構築する際の認証認可、アクセス制限のパターンを何となく説明しています
Kubernetes Meetup Tokyo #4 https://k8sjp.connpass.com/event/53737/
原文：Cloudera Data Science Workbench: Self-Service Data Science for the Enterprise 原著者：Matt Brandwein, Tristan Zajonc 翻訳：有賀 私たちは機械学習の黄金時代に突入しています。それはすべてデータに関するものです。 データの量が増え、計算とストレージのコストが低下し続けることで、世界最大の問題を解決する機会はこれまでになく増えました。 当社のお客様は、すでに高度な機械学習を使用して自動運転車を構築し、病院での新生児のケアを改善し、金融犯罪の防止や、サイバー攻撃の脅威と戦っています。 しかしこれは始まりに過ぎません。 Clouderaでは、お客様がデータを活用することで実現できる限界を広げるためのご支援を行い続けています。 本日、エンタープライズにおいても高速で使いやすく、セキュアな
ファッション系の通販モールとして人気のZOZOTOWN（ゾゾタウン）でなんと、ツケ払いが利用可能になったようです。ゾゾタウンの運営会社であるスタートトゥデイが公式リリースにて発表しました。 ZOZOならお支払いは２ヶ月後！「ツケ払い」を開始 株式会社スタートトゥデイ（本社：千葉県千葉市 代表取締役：前澤友作）が運営するファッションショッピングサイト「ZOZOTOWN」は、商品ご注文日から最大2ヶ月後にお支払いができる新しい決済サービス「ツケ払い」を本日11月1日（火）より開始いたします。 「ツケ払い」では、お支払い期限がご注文日から最大2ヶ月後となるため、お財布事情を気にすることなく、お客様のご都合のよいタイミングでZOZOTOWNでのお買い物をお楽しみいただくことができます。 中身はコンビニ後払いと同じ仕組み： 『えっ！ZOZOでツケ払いが出来るようになったの！』と驚かれる方は多いかもし
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog OpenStackの運用エンジニアをしている木下です。 今回はマルチプラットフォームCI環境に関する連載の第4弾として、KubernetesとOpenStackの連携を検証した際に分かった、動作させる手順と現在の状況について説明していきたいと思います。 本エントリーでは、「Kubernetesの認証としてKeystoneを利用する方法」、「KubernetesからCinderを利用する方法」の2つを詳しく解説していきます。 本エントリーで検証したKubernetesのバージョンは1.2.2になります。 Kubernetesの認証としてKeystoneを利用する Kubernetesの認証・認可の機構に関して簡単に説明したあと、Ke
Документ содержит информацию о различных аспектах обсуждаемой темы. Он затрагивает ключевые вопросы и мнения экспертов. Текст объемный и охватывает множество связанных подтем.
From Zero to Hero with REST and OAuth2 #jjugAI-enhanced description The document discusses authorization using OAuth2 and securing REST APIs. It begins with an introduction to OAuth2 terminology and flow, including the authorization code grant and resource owner password credentials grant types. It then covers using JSON Web Tokens (JWTs) as access tokens, explaining that JWTs can be verified at s
シトリックス・システムズ・ジャパンは2016年6月17日、アプリケーションやデスクトップを仮想化するソフトの新バージョン「XenApp 7.9」「XenDesktop 7.9」を発売した。複数のログイン認証方法を共通化して使えるSSO（シングル・サインオン）機能を追加した。 SSOは、1種類の認証を済ませることで、本来はそれぞれ異なる認証が必要な複数のサービスを透過的に利用できるようにする仕組み。新機能は、SAML連携型のユーザー認証サービスと連携できる。 例えば、一時的に業務に従事する派遣社員や協力企業の従業員に対してActive Directory（AD）のアクセス権限を与えるとき、派遣社員や協力企業の従業員がSAML連携型のほかの認証サービスを利用していれば、それらを使ってADのアクセス権限を与えるなどができる。 営業推進本部プロダクトソリューション推進部の竹内裕治シニアプロダクトソ
こんにちは。今日は趣向を変えて千代田区立図書館に来てみました。 www.library.chiyoda.tokyo.jp 図書館は普段あんまり行かないので、地元の図書館との違いに驚きでした。 都内の図書館って広いし綺麗ですね。 九段下から割と近い、置いている蔵書のジャンルが多し、席のジャンル多し、無線Wifiあり、電源あり、でかなり使いやすかったです。 静かで落ち着いた雰囲気で過ごしやすい気がしますが、無音なので独り言が多い人は気をつけてください。 さて、前回の記事について@okeee0315さんからこんなコメントを。 認証回りは大事、ADの前に認証と認可が必要かも / ADなにそれおいしくない(泣) - どんまいこのネタ帳 https://t.co/MEFI6o5qNA— okeee (@okeee0315) 2016年5月3日 ほほう。ADはまだ美味しくなかったので、教えに従い認証周り
eiwg_utilization_guideline_2.0.pdf 構成 1.エンタープライズIT におけるフェデレーションとプロビジョニングの有用性 2.OpenID Connect の概略と構成例 3.アイデンティティとトラスト 4.権限委譲の適用と課題 『OpenID ConnectとSCIMのエンタープライズ実装ガイドライン』 クラウドサービス事業者およびクラウドサービス利用企業で、認証基盤の開発、運用を行なう方を対象に、OpenID Connectを使った認証連携 (SSO) と、SCIMを使ったアイデンティティ管理（ID管理）により、利用企業の認証システムとクラウドサービスを相互接続、相互運用するための、一般的かつ最小限の実装について、具体的な例をあげながら解説しています。 eiwg_implementation_guideline_1.0.pdf 構成 1. はじめに 2.
認証は単純な概念で、別の言葉で言えば本人確認です。Web サイトにおける本人確認の最も一般的な方法は ID とパスワードの組を提示してもらうことですが、指紋や虹彩などの生体情報を用いた本人確認方法もありえます。どのような確認方法だとしても (ワンタイムパスワードを使ったり、2-way 認証だったりしても)、認証とは、誰なのかを特定するための処理です。開発者の言葉でこれを表現すると、「認証とは、ユーザーの一意識別子を特定する処理」と言えます。 一方、認可のほうは、「誰が」、「誰に」、「何の権限を」、という三つの要素が出てくるため、複雑になります。加えて、話をややこしくしているのは、この三つの要素のうち、「誰が」を決める処理が「認証処理」であるという点です。すなわち、認可処理にはその一部として認証処理が含まれているため、話がややこしくなっているのです。 認可の三要素をもう少し現場に近い言葉で表
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
