2025年に入ってから日本の証券口座を狙ったインターネット取引サービスに対する不正アクセスや不正取引が急増しているとして、金融庁や日本証券協会は利用者に注意を呼び掛けています。ここでは関連する情報をまとめます。 2024年末から被害急増 国内の複数の証券会社で不正取引の被害が相次いでいる。これは、何者かが証券会社のインターネット取引サービスに不正アクセスし、顧客の資産を勝手に売却したり株式を購入したりするもの。 2025年3月に入ると、SNS上で楽天証券の被害に関する投稿 *1が話題となり、同社も不審なメールへの注意を呼びかけたうえで、3月23日からリスクベース認証を導入した。*2 楽天証券は、この不正取引について2024年末からフィッシング詐欺の増加や被害が確認されていたことを明らかにしている。*3 SBI証券でも同年3月、中国株を利用した不正取引が確認されており、件数は楽天証券より少な
パスキーによる認証を開発したとき、パスキーの安全性をどう評価するのが妥当なのか検討していた。もちろんフィッシング耐性が高いというような特性については把握していて、サービス利用者にとって便益の多い認証であることはわかっている。ただそれが、例えばパスワードとTOTPを組み合わせた多要素認証に対して、どちらがより安全と言えるのか。これを一言に表すのはあまり簡単ではない。 パスキーは多要素認証なのか 多要素認証というのは、something you know、something you have、something you are の3種類の要素のうち複数を組み合わせる認証を言う語だ。 多要素認証は単一種類の要素による認証と較べて飛躍的に安全である。例えば、物理的な鍵は something you have であるが、それが盗まれてしまえば安全ではない。鍵が複数あっても、一度に盗まれてしまうかもし
既存プロジェクトにNext.js等のSSRを導入する場合は既存の認証機能を維持したり活かしたりする必要があります。しかしSSRの認証とCSR(SPA)の認証は同じではなく、簡単に共有できるものではありません。 ここでは複数のテックブログの事例を見ながら、この難しさと本物のウェブサービスで採用された解決策を見ていきます。 CSRとSSRの認証の違い まず最初に、CSR(SPA)とSSR[1]の認証の違いをざっくり紹介します。技術的制約を理解していただくことが目的です。 クライアント視点では、認証システムは突き詰めると、トークン(鍵)[2]を安全に保管し、必要時にサーバに渡す(鍵穴に差し込む) ことです。この２つに絞って解説します。[3] https://www.flaticon.com/free-icons/vault (by IYIKON) https://www.flaticon.com
本稿はJCB Advent Calendar 2024の12月14日の記事です。 3-Dセキュアにおける認証取引の仕組み解説 JCB デジタルソリューション開発部 アプリチームの村井です。 アプリチームではJCBが提供する様々なサービスの開発・運用をしています。 今回は非対面のクレジットカード決済で導入が進んでいる3-Dセキュア（本人認証サービス）について、 各システムの動きにフォーカスして認証取引の主な仕組みを紹介します。 3-Dセキュアの認証取引の仕組みは、提唱元であるEMVCoのサイトから公式ドキュメントをダウンロードできます。 本記事では公式ドキュメントの内容を噛み砕いて解説します。 そもそも3-Dセキュアって何？という方は過去の記事もご覧ください。 認証取引 認証取引の概要を図示します。 JCBではDSシステムを運用しています。 また、アクワイアラドメインで稼働するシステムが3D
これは何? GitHub ActionsからAWSのリソースへのアクセスする際にはなんらかの認証情報が必要です。 一昔前は，GitHub Actions Secretsに保存したAWSのアクセスキーとシークレットを埋め込む形が一般的でした。 しかし，最近この方法は非推奨になっています。 本記事では，Open ID Connectの技術を利用することによってよりセキュアにGitHub Actionsを使用する方法について紹介します。 OpenID Connectとは https://www.openid.or.jp/document/ より抜粋 OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server の認証結果に基づいて End-Us
はじめに 2023年4月に基盤エンジニアとして Ubie に入社しました nerocrux です。主に Ubie の ID 基盤の開発と保守運用を担当しています。 この記事は、2023 Ubie Engineers アドベントカレンダー 5 日目の記事となります。 Ubie では、モジュラモノリスを採用しつつ、マイクロサービスアーキテクチャも採用しており、領域によってサービスを分けて、それぞれの担当チームが開発と保守運用をしています。 クライアントから一つのリクエストを受け取ったあとに、Ubie のバックエンドではリクエストを受け取ったサービスだけがそのリクエストを処理することもあれば、別のサービスにディスパッチし、複数のサービスがひとつのリクエストを処理して結果を返すこともあります。 マイクロサービス間の通信が Ubie の内部で発生したとしても、必ずしも無制限で自由に行われていいわけで
ritou です。 みんなが待っていたデジタル認証アプリの情報が公開されました。 開発者向けのガイドライン、APIリファレンスなどのドキュメントも公開されています。 今回は開発者視点でどんな作りになっていて、利用するために理解が必要となる標準化仕様はどのあたりなのかを取り上げます。ちょっとOIDCのRPやOAuthのClient実装経験のある開発者向け、ぐらいの内容です。 概要 公開された情報からすると デジタル認証アプリサービス(アプリ+バックエンド)はマイナンバーカードを用いた当人認証を実施 現在は都度マイナンバーカードを利用する必要がありますが、いずれはスマホに保存されたカード情報を使ってもっと楽になりそう ID連携のIdentityプロバイダとして認証イベント情報、基本4情報といった属性情報を民間/行政サービスに提供 民間/行政サービスは認証イベント情報に含まれるユーザー識別子を利
英語の「Authentication」を整理する ここからは先ほどの分類で言うところの「ユーザ認証」としての「認証」、つまり英語の「Authentication」に該当する「認証」について、さらに整理を進めていきます。 先ほど、「ユーザ認証」を「システムを利用しようとしているユーザを、システムに登録済みのユーザかどうか識別し、ユーザが主張する身元を検証するプロセス」と説明しました。「ユーザの識別」と「身元の検証」はユーザ認証に欠かせませんが、実際は他にも「ユーザの有効／無効状態の確認」や「検証に成功した場合の身元の保証（アクセストークンの発行等）」などの処理も一般的にユーザ認証のプロセスには含まれます。 ここで冒頭の「○○認証」を振り返りましょう。パスワード認証、SMS認証、指紋認証、顔認証は実はここで言うユーザ認証には該当せず、ユーザ認証中の一処理である「身元の検証」を担っていることがお
ritouです。 サービス、ブラウザ、OSそれぞれのパスキー対応が日々進んでいます。 その中で、パスキーを利用してみて認証要素についてふと考えてしまう人がいるでしょう。 パスキー簡単！けどこれ指紋認証だけ？弱くなってない？ SMS OTPを2FAに設定し、パスワードマネージャーも使ってたから使い勝手はあまり変わらない。むしろSMS OTPがないぶんだけ弱くなった？ この辺りについて整理します。 認証要素というと、次の3つです。 SYK: Something You Know. パスワード、PIN SYH: Something You Have. 認証アプリ、TOTP生成アプリ、バックアップコード、 SYA: Something You Are. 生体認証 前にこんな記事を書きました。 この内容を説明すると、「うん、わかってる」って人は多いです。 でも、実際に使ってみると心許なく感じたりする
SPAやモバイルアプリから利用するAPIを開発する際の、トークン認証のお話です。 どの認証ライブラリを使うべきという話ではなく、トークン認証の論理的な設計について考察します。 私自身も結論が出ていないので、色んな意見が聞けると嬉しいです。 出発点 ユーザテーブルにアクセストークンを持つのが最も安直な発想だと思います。 ログイン成功時にアクセストークンを発行し、該当ユーザレコードにセット。 同時に有効期限もセットします。 認証時には、アクセストークンが存在し有効期限内であれば、認証を通過させ、 そうでなければ認証失敗とします。 ログアウト時には、該当ユーザレコードのアクセストークンを空にします。 発行日時を持ち、システム内に定義された有効期間をもとに、認証時に計算する方法もあると思います。 Laravel Sanctum 等はそういう実装です（しかもデフォルトでは有効期限なし）。 有効かどう
2023.01.24 経済産業省、全ECサイトが義務化対象 セキュリティー対策で脆弱性対策と本人認証導入を義務化 0 経済産業省は1月20日、ECサイトの脆弱性対策と本人認証の仕組みを導入することを義務化する方針を固めた。2024年3月末までに、全てのECサイトが脆弱性対策と本人認証を導入することを、検討会の報告書案に盛り込んでいる。 ECサイトと本人認証の仕組みの導入の義務化は、「クレジットカード決済システムのセキュリティ対策強化検討会」の第6回会合で提出された報告書案に盛り込まれた。 報告書案では、クレジットカード番号の不正利用被害が増え続ける問題を背景に、「ECサイトからクレジットカード情報が漏洩することへの対策」「漏洩したクレジットカード情報が不正に使われることへの対策」の2点を盛り込んだ。 具体的には、「クレジットカード番号等の適切管理義務の水準を引き上げるべく、サイト自体の脆弱
最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。 数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述) 何故こんなことが起きるのか そもそも、フロント側に何故IPアドレスを送ってんだ、という話です
複数のクラウドサービスを利用している（マルチクラウド）など、単純には閉域網を構築できない環境でマイクロサービスアーキテクチャを採用する場合には、サービス間の認証認可が必要となる。この場合のサービス間の認証認可方式を決める参考となる、OSSやSaaS、Webサービスで採用方式ついて整理した。 Istio サービスメッシュの実装として有名なIstioではサービス間通信を以下のように制御できる。 Istioの認証認可では認証主体がService Identityというモデルで抽象化され、KubernatesやIstioで定義するService Accountに加えて、GCP/AWSのIAMアカウントやオンプレミスの既存IDなどをService Identityとして扱うことができる。 サービス間の認証 (Peer Authentication) は、各サービス (Pod) に設置するSideca
"Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~"の発表資料です。 https://connpass.com/event/142624/
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDayAI-enhanced description The document details the AWS Dev Day Tokyo 2018 event, featuring various discussions and topics related to AWS technologies. It includes mentions of sessions, coffee breaks, and interactions among participants, along with multiple hashtags related to the event. The document is primarily a collection of tweets and notes ref
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く