免許証・マイナ保険証と本人確認
こんにちは、シニアソフトウェアエンジニアのriddleです。
こんにちは、ミドルソフトウェアエンジニアのひびのです。
このポッドキャストでは、僕たちゲーマーが、
最近のセキュリティ対策、皆さん何してますか?
いえーい、はい。
いえーい、セキュリティは国だっけ?
なんかあの、いわゆる公的な、これは危ないぞ、人間みたいに呼びかけられる程度増えてますよね。
そうですね、毎日のようにどこどこで何万件何千万件の情報漏洩がしましたみたいなね。
特に最近だと免許証が漏洩したタイムズ見たところもあって、
僕もアカウント登録してたんで、速攻で見に行きましたね。
いや、僕もタイムズさんなので。
出ましたね。
俺なんかちなみに見に行ったらさ、免許証登録されてなかったし、
何なら多分登録されてるやつって2015年とかだから絶対執行してるからいいんだけど、
氷室さんはヘビーユーザーということで、どういう対応したんですか?
特に対応していないというか、なんか話していいのかな。
僕の場合は、とても幸運なんだけど、来月免許更新なんだよ。
あ、なるほど。早く来い、来月。
で、なんか免許の更新とかするよね。
免許の再発行すると、免許の番号の下一桁が繰り上がっているみたいな仕様があるみたいで、
で、なんか言ってみたら再発行の数が多いと、
死ぬみたいなことが言われてるらしいんですよ。
で、あと1ヶ月で執行すると思ってしてます。
なるほど。ありがとうございます。
でもなんかふと思ったんだけど、結局さ、期限が切れたり番号変わってもさ、
AIで今の撮られた画像をベースにちょっと作り変えられて数字変えたら使えるんじゃない?
そんなことないのかな?
確かに、オンラインで何か申請するときの画像を撮っていって、
言ってみたら今のオーバー、割とすんなりそれっぽい画像を作っている。
あれって画像で保存してるんじゃないのかな?どうなんの?
どうなんでしょうね。いわゆるいい機器って言うんですかね。
免許を取って本人が。
あれって多分、免許証の画像を取ってはいるけど、
あれを発行してる警察、そういう大元の機関に別に釣ってるわけじゃないですよね。
懸面のね、表面とか厚みとか、それぐらいな気がするから。
でもなんか今ニュース見たら、5日前のニュースが5日前だから10月9日だけど、
本人確認はICチップ一本買い早期移行を金融庁が要請してますね。
写真だとダメだからチップにしようっていう。
あれと同じですね。マイナンバーと。
チップか。ってことはオンラインで今後するときは、
それこそNFCで何かしらの機能がなくなる?
そうですね。でもスマホでできるじゃないですか。マイナンバーは。
確かに。
あれと似たような感じで免許証もやるみたいな。
初めてやったけどどうしたね。マイナンバーとか。
本当に入ってるやつですね。
あとそれで言うと、一応もう免許証の日取りを事前に予約してるんですよ。
東京都はもう入っていけないみたいで今。
そうなんだ。
で、今選択肢として懸面のみ再発するか、それかマイナ免許証のみ作成するか、
あるいは両方作成するかの3点ですよ。
免許証っていえばマイナンバーに投稿されてるんだ。知らなかった。
マイナ免許証が。
おそらくあれですよね。マイナ免許証で取り替えればスマホの情報も兼ねるのかな?
マイナ健康証保険?健康証明書みたいなやつが出たときに、
アップルまだ対応してないですとか、アンドロイドまだ対応してないですとかしたから、スマホに入るかどうかまたちゃんと確認しないとわかんないんじゃないかな。
まだダメだ。現時点においてはダメって出てきたわ。ジェミニが回答してましたわ。
健康保険証病院受診するとき保険証出すじゃないか。
僕、保険証忘れちゃって。
僕まだマイナ保険証と、それからIT憲法からもらったカードの方を懸命に2つ持ちなんですけど、忘れちゃったんですよ。
で、その時マイナポータル開いて、マイナポータル開いたらマイナ保険証が入ってるか、非保険者番号がわかるんですよ。
その番号だけ見せてもらえばいいですよって。
そうなんだ。それでもいけるんだ。
確かにあれですよね。これまで健康保険証で見せるっていうのを振り返ると、別に何かをスキャンしてる、チェックしてるわけじゃなく、ただ単に番号を照らしたかと思って。
そうなんだ。中でやってるから全然わからなかったな。
なるほど。
まあでも未だにね、怖いからマイナ健康保険証にはしてないね。
僕はそれで言うと、今回の免許証については、いわゆる両方発行してもらう2枚持ちの方に。
絶対そっちの方がいいよね。
ちゃっても免許証がある、みたいな状態を作りたいな。
そうね。片方なくしたときさんだからね。両方一緒になってると。片方じゃねえか。その一体型をなくすと無理。お前は誰だの証明がめっちゃむずい。
パスキー認証の利便性と課題
そうか。それで言うと、あれですよね、ウェブサービスで言うところなんですけど、認証の仕組みも何と言うか、
あれですよね、導入しましょうとか、あとはパスキー導入しよう。
なんかいろいろサービス側でのですよね。
そうですね。二段階認証もね、最近はじくというか、やめてパスキーオンリーにするみたいなの増えてるから。
我々はITエンジニアだからいいけど、知らない人は無理じゃないですか。この前妻に聞きましたけど、パスキーって知ってるって聞いたら知らないって言われました。
最近若者人気のアプリ、セットログってあれですか?
なんかBDRみたいなやつ。俺も始めたけど、連絡先誰とも交換しなくて、あまりにもつまらなすぎて、何もできないからやめてしまった。
あれ、認証パスキーオンリーです。
そうなんだ。
若者向けなのに、なんと尖った。有名な話ですよ。僕も使わせていただいて。
でもこれさ、パスキーオンリーの方が逆に楽なんじゃない?だって管理しなくていいじゃん、ほとんど。
そうなんですよ。アプリを初回起動したときにメールアドレス見る。あとはパスキー。
何というか、ユーザー目線だと匿名認証くらいの手軽さでいけるっていうのは、セットログって驚きでしたね。
確かに。今ってクロスデバイスだとどうなるんだろう?
iPhoneからiPhoneへの移行は別に、普通にiCloudキーチェーンとかあるし、AndroidもGoogleのパスワードマネージャーあるけど、みんな別にワンパスワードみたいなパスワードマネージャ
ーって入れてないじゃないですか、普通の人。
そうですよね。
普通もうクロスデバイス、iPhoneからAndroidに移行したときとか、そのあたりってシームレスにやってくれるのかな?
そうですね。iOSだとiCloudの図。Androidも確かちょうど最近見たんですけど、来年3月か4月の規約変更。
言ってみたら、そのクロスデバイスでAndroid側でキーチェーンを保存して、端末移行した時にキーチェーンにしても新しいデバイスで使えるようにならなきゃいけないのを各アプリベンダーに義務化してする。
アプリベンダー側でやれってこと?
そうです。AndroidのいわゆるキーチェーンのAPIに紐づけるのが。だから最近にAndroidもあるんですね。
なるほどな。それ大変じゃないか。
大変だと思います。
アカウント周りをしっかり整備しているサービスなら、結構雑に区名認証を運用しているアプリとはだいぶきついんじゃないか?
もともと長いことやってるプロダクトなんて、最初は普通にメールアドレスとパスワードみたいな感じでやってたのに、急に途中から2段階の認証を入れましょうとなって、今になったら今度は2段階の認証じゃなくてパス
キーを入れましょうと認証方式がどんどん変わっているから、きつそう。
そうですよね。今でこそGoogle Appsとか、例えば、今あるかわかんないけど、レガシーなTwitterログインとかまだ運用しているところあったら地獄ですよね。
AI時代のAPI・クラウド防御
ちなみに話がだいぶ脱線してしまったんですが、もともと話すのは、さっきのAIにおけるバックエンドとかインフラ側のセキュリティを話そうと思ってたんですね。
企業側のAPIで用意する、最初の言い口の認証のところの話でもあるんですけど、もうちょっと他に、今いろんなAPIホスティングしているサイトってあるじゃないですか。クライアントとかフロントエンドとか叩くわ
けですけど、その辺でどうやって守ってます?
ALBとかロードバランサーの時点でまず、海外からのアクセスとか、過去に不正アクセスしてきたAIとかは、まずそこでガチですよね。
L4とかL7のレイヤーで一手弾くと、WAFで、WAFとかセキュリティグループかな、AWSだと。
セーフなり、クラウドなりですかね。
つい昨今の、ちょうど最近見た記事で、AIによってAndroid、iOSのアプリのバイナリの解析が相当容易になって、
デバッグAPIとクラウド設定の監視
例えば、それこそ、アプリ開発していると、オープンAPI定義にいろんなAPI定義を載せて、そこからAPIクライアント生成プリにバンドルするみたいな的じゃないですか。
そこで、もう廃止してたりとか、あるいはデバッグ用のAPIエンドポイントが最近あるみたいで。
つい最近、デバッグ用のAPIと、あとはアプリユーザー向けのAPIと改めて思いましたね。
それは、クライアントのソースコードにデバッグ用のAPIのエンドポイントが見えないようにするじゃなくて、守る側のほうで叩けないようにする?
見えないように、そもそも第三者に設置されてもわからない。
あともう一つはあれですよね、本番サーバーではそもそもそれをデバッグ用にするの2面ですよね。
そうですね。でもなんかふと思ったんですけど、怖いなと思ったのが、バックエンド側のデバッグ機能のオンオフって何かしらの方法でやるじゃないですか。
起動引数なのか、環境変数なのか、フィーチャーフラグ、フィーチャーフラグはないか。
あれって、if文1個じゃないですか?怖くないですか?
まあ確かに、何かしらの人為的なミスで公開されるものではありますよね。
いずデバッグトゥルーかどうかしら、あれめちゃくちゃ大事なif文過ぎて怖いなと今ふと思った。
なんかいわゆるそこはあれかもしれないですね、外形監視のほうで、外側から本番のAPIサーバーでは公開されてはいけないエンドポイントなのを検査はしたいですよね。
確かに、それいいな、今度やろうかなそれ。
僕も今思いついた言い方ではありますけど。
AWSコンフィグみたいなのはちょっと近い思想かなと思うんですけど、外形監視じゃないけど設定に不備があるAWSの設定があれば、それを通知してくれるみたいなやつあるんですよね。
変なポート開いてるセキュリティグループとか。そういうのでもいいかもな。
でもそうなるとあんまり、そうか。
開くってわけじゃないけど、未然逆性を防ぐ、あれなんて読むんだろう。
TRIV?
TRIVですかね。
セキュリティスキャナーですよね。前攻撃されちゃった。
ですです。
リットハーフアクションズにコードを検査したりとかはやってたりですね。
いいですね。
ああいうオープンソースのスキャナーとかは非常に役立ちますよね。
公開情報で、僕のいる会社ではWizっていう監視ツールで、クラウドとかGitHubとかいろいろなりしますね。
そうなんだ。クラウド系の設定とかをチェックしてとかそういう感じなのかわからないけど。
エンドポイントが公開されてないかとか。
シーナップっていうクラウドネイティブアプリケーションプロテクションプラットフォームの製品としてWizっていう名前のようなもの。
何をやってくれるかというと、クラウド環境の設定ミスやコンテンツ違反、外部公開リスク、AWSコンフィグとかガードデューティーみたいな。
あとは仮想マシンのコンテナのサーワークロードを保護。
で、IAMとかロールの過剰電源やアクセス管理を監査。
あとはKubernetes環境のセキュリティリスク管理とか、IACとアーティファクトのスキャン。
なるほどね。確かにミクシーみたいなマルチクラウドをいろんなサービスでぽこぽこ使ってたりするところだと、
クラウドを越境したようなツールを全社席に入れるのは結構いいですね。
最近AIミクシーさん結構使ってるけど、AIエージェントでセキュリティでチェックするような世の中も来ると思うんですけど、
攻撃側じゃなくて防御側として。そういうのとか経験ありますか?
経験。僕自身意識したことはないんですけど、例えば新規のエンドポップになったら、
AIを活用したコード検査とKubernetes防御
割とこれこそ入力される値のバリデーション、割とAIがよしなに言ってくれちゃいますよね。最近だと。
確かにそれはある。
一応僕もそれはやった方がいいという意識で、AIの書いたコードをチラッと見たら、しっかりやってくれてるな。
なんかこれ自分はやったことないんですけど、テストの一つに何だったかな?
ランダムな値を入れまくってテストをするみたいな、そういうのがあった気がして。
モンキーテストっていうのかな?
なんか聞いたことはある気がする。
モンキーテストって名前じゃなかった気がするんだけどな。
ファジング?じゃなかったかな?忘れてたわ。
ファジングだわ。ランダムまたは意図的に生成されたデータを対象システムに投入し、その反応を観察することで、
なんか変なことが起きないか、その反応を観察することでバグや脆弱性を検出するみたいなやり方があった。
ペンテストってあるじゃないですか。要するにこういう風にこういう仕様みたいなのを決めてやったりする。
セキュリティのエンジニアがやる手法とかあるんですけど、そういうのじゃなくてもっと雑にいろんなもの投げていくみたいな。
これだから別にAIでコード解釈も結構有用な気がするんですけどね。どんくらいこう…
やったことない。
いついいテストの一つとして持っておくとくなりにしておくみたいなのはやってもいいかもしれない。
そうですね。ファジングテストも別に多分やるのは簡単そうな気がするんで、全然環境整っていればすぐできそうだけど。
最近自分がやってるやつで言うと…
まず二分割するとして、要するに今動かすアプリをこれから作るまでの話と、それをデプロイした後の話で分割できると思うんですけど、
コードを要するに書いてマージするところは、いわゆるスキャナーとか、いわゆるリゾンライブラリとかのバージョンチェックとか、
それをダイジェストで固定するとか、ハッシュ固定するとか、クールダウンつけて標的型攻撃のゼロデリとかに引っかからないようにするみたいなのは、
まあまあみんなやりますよねみたいなラインでやりますよね。
そっからデプロイした先は多分ひみのさんとほぼ同じで、結局IP制限系のL4系とか、WAFでL7を防いだりとかっていうところから、
あとはその実際にアクセスさせられるアプリがどんだけ堅牢なのか、そこのアプリが例えばコンテナとかで動いたら、
ボットの設定としてルート昇格できないようにするとか、リードオンリーのファイルシステムにするみたいなことは当たり前のようにやると思いますし、
あとはKubernetes側だと結構その何のシステムコールまで許容するかみたいなことも結構選べたりするので、
そういうところを設定したりする。
あとKubernetesの話になっちゃうんですけど、
PodやKubernetesのAPIの叩き方が想定と違うものだったら弾くみたいな、そういうミドルウェアもあったりするんですよ。
例えばですか?
例えばですけど、普段はアクセスしないようなシークレットに対して、
アクセスが発生した場合に、それって良くない行為だよねみたいなのを判断してブロックしたりとか、
あとは例えばConfigMapとかの内容をいつもの違う経路で書き換えようとするとブロックされるとか、
そういうのもあったりとか、あとはこれはまた違う話なんですけど、
DockerイメージをKubernetes上で起動するときに認証されていないイメージが起動できないとか、
なんで、知らないサードパーティーのコンテナをいきなりプルされて起動するみたいなことをやられたときに、それを防ぐみたいな、そういうのもあったりしますね。
でもKubernetes側で意図しないイメージのことですね。
Kubernetes単体というよりかは、そういうのに特化したセキュリティ系のOSSとか入れて実現するというほうが近いですね、それは。
いろんなことができるんですね。
多層防御とAIによる攻撃への対策
そうなんですよ、だからこれって別にセキュリティってこれ入れておけば絶対解決するみたいな方法で、考え方としては多層防御なので、
いろんなところでちょっとずつ守っていって、結果として堅牢にしていくみたいなことが多いんで、
これだけやっておけば大丈夫かんじゃなくて、いかに自分の手札を揃えておくかというか、いろんなところから情報を集めて、いろんな手法を集めて、
かつてそれが運用に乗るレベルの使用感でいけるのか、みたいなのを考えながら、とはいえ破られたら何もできないですけど。
まあ確かに。
っていう感じかな。
そうだな。
そのKubernetesみたいなものって割とそのECSがクラウドランに比べると自由度がめちゃくちゃ高いんですけど、
そうすると結局そのセキュリティの面倒ってどうしても運用する我々が見ないといけなくなっちゃうので、
そうするとじゃあそのKubernetesをまあとりあえず設計構築できますっていうのと、
あとそこから障害対応できますっていうやつのさらに上にKubernetesにおけるセキュリティのメンタルモデルを理解した上で、
ちゃんといろんな経路からの攻撃を防ぐ方法をちゃんと知ってるのかみたいな、なんか新しい知識が必要になって、
それ自信持ってできますっていう人ほぼいないと思うんですよね。
だっていろんな経路で来るし、
俺も全然わかんないし、ってなるとめっちゃ作業しづらくないか。
確かに、そこまで行くともはやプラットフォームチームしか触れない代物になっちゃう。
まあそうですね、とはいえ結局簡単にPod起動するぐらいの状況だったとしても、
そのPodに対してどういうセキュリティルールを設定するかとかはアプリケーションがもう考えないといけないから、
まあ、プラットフォームチームがだいぶ厳しくやってくれてると思うんですけど、
なかなか厳しいですよね。
ちゃんとセキュリティまで意識してやろうと思うと、今のご時世。
確かに。
なんか僕は結構、フロントアプリケーション下でアプリケーションを最近使うんですけど、
リノベートが立てたパッチを頻繁に。
ああそうね、そうそうそう。
その辺りのきまちましの再作業みたいなのは割と。
確かに、リノベートにマージして自動デプロレスが通ってデプロレスされるっていうところまでは、
ちゃんと務めておかないといけないよねっていう。
そうですね。
そうですね、そういう意味ではの数とか、あと依存しているパッケージの数によって。
あと、これまでどれくらい放置されてきたか度合いでもだいぶ対応の難易度が。
確かに。
Railsとのバージョンとか何個か古いみたいになると大変だし、
そう考えるとやっぱり高方向間性の高い言語とかフレームワークとかを選定しておいた方が、
1回上げるごとのコストがあんまり高くないからいいのかもね、この時代。
そうですね。
ノードケースのパッケージとか、パッチで頻繁に破壊的な変更を入れていく。
そうね、よくないよね。
あと、頻繁にメジャーバージョンが上がるのも結構きついというか。
リアクトとかなんですよ。今、いくつ?今、いくつ?
26ぐらい。
今、いくつ?たぶんそれくらいだと思います。
あと、19.3になったわ。全部嘘ついたわ。
パッケージによってはめちゃめちゃ細かく本当に1日単位でパッチ出してるパッケージとかもあります。
そういうのもなかなかしんどいですよね。
そうですね。今まだできてないと思うんですけど、AIで攻撃が激しくなってきてると思うんで、
特にAPIサーバーとかはやおもてに立つかな。ここに対してもうちょっと有効な手を1個増やしたいな。
AIでブロックするみたいな。レイテンシーやばいことになりそうなんですけど。
JEVってやつあるじゃないですか。判断だけをしてくれるAI。
あれがどれくらいのレイテンシーかわかんないけど、応答時間は70から500msって書いてある。
ちょっとAPIの後ろに、例えばペイロードを丸ごと食わせて、怪しいか怪しくないかみたいな判断させて、怪しくなかったら通すみたいな使い方できないかなってふと思ったんですけど。
外部じゃなくてローカルのLLMとして動かすみたいな感じですけど、70から500msかかったらきついな。
完全にジャストアイディアですけど、いわゆるそういう外部からAPIサーバーに攻撃と短期間に大量のリクエストを送ってくるとか、あとは継続的に何回もリクエストを送ってくると思ってて。
全リクエストの中、一部のAPIでサイドエフェクトとか横でこのIPアドレスからのダメだと判断したら、次からそいつをやり方をもしかしたらできるかもしれない。
ミラーリングしておいて、他のところで検証だけしておいて、検証結果だけを後でシンクするみたいな感じってことか。確かにそういうのもありますね。
僕は素人なんですが、もう少し叩かれる回数がなくて勝つミッションが、ウェブ予約サービスの予約エンドポイント、あとはEU関係のサービスの送金エンドポイント、そういうところにだけ入れるみたいなのも。
どこまでの情報でどのくらい判断してくれるんだろうな。例えば、ID5からID6に100円を送りますみたいなやつ渡されても、判断できる材料なくて、ジェブさんも判断できないのかな。
確かに。
だから、HTTPリクエストみたいな丸ごといろんなメタデータとかついてるぐらいのものじゃないと判断できないんじゃないかという気がしてる。
あと、なるべく生の情報のほうがいいのかな。
入られることを前提にして、入られたとしても何にもできないようにする感じがいいんだろうなと思いつつも、
例えばですけど、データベースと通信するAPIサーバーがいて、そこに入られました。そこに入ったら結局そいつができることって全部できるもんじゃないですか。普通に考えたら。
要するに、例えばそのアプリからつながってるデータベースには、そのアプリの権限で普通にアクセスできちゃうじゃないですか。
そうですね。
だから、そう考えると入られたで、もちろんそのデータベースっていうのはネットワーク的なリーチャビリティもあるわけですから、もう無理じゃない?入られた時点で。
まあ、入られちゃったら。
コマンドも無いから。
そうですね。入られたら。え、防げるのかな?どうやって防ぐんだろう?
クレデンシャルがアプリケーションのメモリーにしかないとして、そのメモリーがダンプできたとしたら認証も取れるから。
そこを防げないと入ったら終わりみたいになるの嫌だな。
入ったら、例えばPodだったらすぐキルしてくれるみたいなね。ちょっと疑わしい動作だったら。
これコンテナのランタイムスキャナーみたいなやつでもそういうのあるんですけど、それぐらいかな?分かんないけど。
結局他のPodにやられるけどね、それ。
同じ攻撃。
いやー、でもコンテナまで到達されたら何にしろなすべがないというか、Podキルするにはまたやられたら終わりだし。
ディストロレスとかハーデンみたいなほぼ何にも入ってないコンテナにしておくっていうのは前提ですけど、
みんなすごいテクニックを使ってすごいことやるから。
多分攻撃する側もAIを味方につけてあれこれいろいろ考えていると対策していくしかないですよね。
イタチごっこのような。
そうですね。じゃあそんな感じで、今回はAIが非常にセキュリティーに使われているという現状においてどうやって守れるかっていうのと、
何を今しているかっていうところをちょっと経験ベースでお話ししました。
あとはいえだいぶ不足が多いというところではあると思いますので、
皆さんしている方や設計している方はセキュリティーについてもっと学んでより堅牢性を高めていきましょう。
じゃあありがとうございました。
このポッドキャストはハッシュタグUITで皆様の感想やコメント募集しております。
またチャンネルの概要欄にありますGoogleフォームのリンクからもご投稿可能です。ありがとうございました。