Vol.114の特集2を読んだこともあって、理解を深めるためにWebAuthnでの公開鍵登録(今回はサインアップを兼ねる)、認証だけできる簡単なWebアプリを作りました。リポジトリのREADMEに様子のGIFアニメを貼っています*1。kymmt90/webauthn_appこのボタンをクリックするとHerokuにデプロイできます。理解できた点WebAuthn自体の詳しい説明は、Web上のリソースを参照したほうがよいので、今回はとくに書いていません。登場する各ロールの役割WebAuthの認証フローを見ると用語が多いですが、概ね次のように理解しました。個人的にRailsだとさっと実装できるので、今回はRailsでやりました。webauthn-rubyとwebauthn-jsonの組み合わせで問題なく実装できます*2。実装項目は次のような感じです。渡して認証器からassertionをもらいサーバへ送るRPサーバは署名、オリジン、チャレンジ値、認証回数の検証などプロトコルに規定されている検証を実行する必要がありますが、ライブラリである程度カバーできると思います。認証体験ふだんパスワードマネージャを使ってはいますが、やはりパスワードレスだと認証の体験がかなり簡単に感じました。これで多要素も満たせる(所持、生体)のも便利ですね。APIを作っていて、外部のサービスからリソースを取得し、DBには保存しないもののレスポンスに含めてクライアントに返したい、ということがありました。このとき次のモジュールが役立ったので紹介します。Recordとも互換性のあるインタフェースでRails上のモデルとして扱える機能がいろいろ入るモジュールです。APIを提供するモジュールです。gem内に含まれるモジュールです。定義した属性からなるJSONをシリアライズできるようになります。これを利用して、次のようなクラスを作りました。外部サービスから得られるリソースを表すクラスを作り、上述したモジュールをincludeします。もとに具体的なリソースを表すクラスを作ります。ここでは外部ブログサービスから記事リソースを取得しているとします。endendこれらを使うと、外部サービスのリソースも含んだJSONを返すエンドポイント自体は、シンプルに実装できます。endendpros/consこの方法の利点は、サードパーティgemのActiveModelSerializersを使うのに比べると、Railsのモジュールだけで実現できてシンプルというところや、モデルとして外部リソースを表現できるので、そのリソースに関するロジックをモデルに置くことができるという点が挙げられます。使って自前の型を定義していくと実装がやや面倒という点です。ネストしているリソースについて型を定義せず、次のように型を指定せずに属性を定義することもできるにはできます。使って書く場面を目撃したり、自分でも書く機会があったので、Railsプラグインに切り出してみました。github.com使い方は次のとおりです。使う、よくある実装になっています。gemにすることですぐに使えるようになって便利ですね。3ドキュメントが使えるようになった点です。3ドキュメント中のスキーマに基づいたJSONレスポンスのバリデーションを自動実行できるようになりました。Vol.108の特集1が参考になります。指定は不要になりました。ついては必須とすることにしました。オプションとして渡さなくなったことによります。正規表現だけでなくふつうのStringも渡せるようにしました。渡された文字列と前方一致するパスを検索して、そのパスで表されるエンドポイントについてはテスト実行時にバリデーションをスキップします。仮に使っている人がいれば、なにかおかしいところがあったら教えてください。よって、クレジットカード加盟店がクレジットカードを扱う際の対応がどのように変わったのか、という点について解説されています。DSSと、国内でのクレジットカードセキュリティの実務指針である「実行計画」に対して、どのように対応していけばよいかについて説明されています。割賦販売法はクレジットカードの根拠法です。割賦販売法が改正されたかというと、主にはカード情報流出対策として加盟店に対するカード情報保護義務を規制として追加するため、という理由があります(他にもある)。実務指針である「実行計画」は、オリンピックが開催される2020年までは毎年更新されるので、訪日外国人のカード決済を保護していくという意味合いも持っているようです。DSSという言葉をよく聞くのですが、実態がよくわからないので知りたかったというのがあります。DSSに対応する場合との違いについても知りたいと思っていました。そもそも非保持化などの対応が必要になった理由を知っておきたかったというところもあります。DSSはクレジットカードに関するグローバルな業界セキュリティ基準です。Council公式サイト一方、日本クレジット協会が発表している「実行計画」は、日本においてクレジットカードのセキュリティ対策をおこなう際の実務的な指針です。2019年版はこちらです。一般社団法人日本クレジット協会クレジットカード情報の「非保持化」は実行計画で示されているものであり、日本国内でのみ採用している方式です。DSSへの対応を求めています。ここで、「非保持化」とは、例えばECサイトをホストしているサーバが生のクレジットカード情報を保存/処理せず、そもそもクレジットカード情報自体がサーバを通過しない、ということを表しています。クレジットカードの電磁的なデータだけがその対象となり、紙媒体や通話録音データは保持に当たらない、と規定されています(厳重に保管する必要はある)。DSSに準拠している必要があります。非保持化の方法Webアプリケーションの開発者的に興味がありそうなのはここかと思います。EC加盟店で非保持化するためには次のような方式が利用できます。リダイレクト(リンク型)決済JavaScript型(トークン)決済リダイレクト決済は、決済サービスのプロバイダが提供する決済用ページへ顧客を誘導する方式です。クレジットカードの処理をプロバイダへ完全に委譲できるのでセキュアですが、加盟店のページと別のドメインのページへとユーザを遷移させることになるので、カゴ落ちが起きやすくなるのが欠点です。JavaScript型は、トークン化などのカード番号無効化処理をブラウザとPSPの間で実行し、そのトークンをEC加盟店のサーバが決済時に使う方式です。トークンはカード番号ではないので、非保持化の要件を満たしています。加盟店のページで決済が完結するのでカゴ落ちしづらいのもメリットと言えます。他の方法として、加盟店のページに決済サービスのプロバイダが提供するモジュールを埋め込むモジュール型があります。これはカード情報を保存はしませんが通過はするので、バックドアが仕掛けられるとアウトという弱点があります。よって、この方式は非保持とは見なされていません。DSSに準拠したサービスとしていく場合、その要件に準拠していることをオンサイトレビューなどで示さなければなりません。選択することで、準拠するための項目を減らすことができます。A)が利用できる、などです。加盟店用のフルセットのSAQであるSAQ-D加盟店だと331項目ありますが、これはけっこう大変そうです...その他2019年からは3Dセキュアの2.0が登場し、ワンタイムパスワードや、怪しい取引に限って3Dセキュアのパスワード入力を求めるリスクベース認証が導入されるようです。DSSへの準拠を求めていることがわかりました。DSSへの対応の際には自己問診票の活用が大事そうということがわかりました。全体的に説明が詳しく、EC加盟店の他に通販や対面の加盟店での対応方法も書いてあり、最近のクレジットカード事情がわかって便利かと思うので、興味のある人は読んでみてください。月別アーカイブ検索スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。