The cause of the vulnerability is actually malicious code present in versions 5.6.0 (released in late February) and 5.6.1 (released on March 9) of the xz libraries, which was accidentally found by Andres Freund, a PostgreSQL developer and software engineer at Microsoft.
https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/
⇧ 偶然に発見した人がファインプレー過ぎるんだけど、これ、もし見過ごされていたとしたら、未曽有の大惨事になっていた気がしますな...
今回、運よく発覚したのだけれど、気付かれていないだけで似たようなことが行われているプロジェクトがある可能性もあるわけで、怖いですな...
ちなみに、
クラウドによる労務管理サービス「WelcomeHR」を提供しているワークスタイルテック株式会社(東京都港区)は、サーバーのアクセス権限設定の誤りにより16万2830人分の個人データが外部から閲覧可能な状態になっていたことを明らかにしました。うち15万4650人分の個人データが第三者によってダウンロードされており、漏えいデータにはマイナンバーや運転免許証のデータが含まれているということです。(画像はWelcomeHRのウェブサイトより)
マイナンバーカードや免許証のデータなど15万4650人の個人データ流出－ワークスタイルテック | サイバーセキュリティ総研
⇧ 日本のSaaS（Software as a Service）で「WelcomeHR」というサービスで、情報漏洩していたみたいですね。
⇧とあるように、サービスを提供する事業者の発表を見た感じでは、年月日の整合性が取れていなかったり、混沌としている...
「マイナンバーカード」とか、どういう状態で管理していたのか気になりますな。
「マイナンバー」の部分が、第三者に確認可能な状態になってしまっているとすると、システムとしてはリカバリーのしようがない気がしますしな...
サービスの利用者に「マイナンバーカード」を再発行してもらう感じになるとしたら、約15万人に影響が出ると...
まぁ、
⇧「マイナンバーカード」だけでも導入が芳しくないのに、「『マイナンバーカード』＋『保険証』」とか強行して、「マイナンバーカード」のシステムが破綻しないか懸念はありますな...
というか、
⇧ 既に破綻しているっぽいですな...
海外でも情報漏洩が起きてますが、
AT&Tによると、このデータセットは2019年以前のものとみられるという。約760万人の現在の顧客のデータについてはパスコード（4桁の数字）をリセットし、全員に連絡した。社会保障番号などの機密情報が漏えいした元顧客にも連絡を取る予定。
このデータセットは、ShinyHuntersと名乗る攻撃者が2021年にダークWeb上で販売を開始したものだ。当時この件を報じたBleepingComputerに対し、AT&Tは「調査によると当社のシステムからのものではないようだ」と語った。
今年の3月になって、サイバー犯罪フォーラムでこのデータセットが公開されたため、データの分析が可能になった。米TechCrunchなどがこのデータにパスコードなどが含まれているとAT&Tに通知したことを受け、AT&Tもこのデータセットが顧客データであることを認めた。
⇧ 漏洩した情報に対する対応が難しそう...
Web APIの権限の設計が難し過ぎるんだが...
開発するWebシステムに依りけりだとは思いますが、Web APIに権限を設定する必要があると思いますと。
基本的には、ユーザー毎で権限を分けられれば話は早いのですが、「然うは問屋が卸さない」という。
このあたりの話は、
⇧ 上記サイト様のまとめを見ていただくのが良いかと。
で、参考サイト様でも仰っているように、Web APIの権限の設計について言及している情報がほとんど無いという...
参考サイト様によりますと、
認可は一箇所で適用するものではなく、様々な場所で様々な角度から適用するものです。そして、様々な場所で繰り返し問い続けるのが認可三大要素（Three main aspects of authorization）です。
認可三大要素は以下のとおり：
-
「誰が」リクエストしているか
-
「何を」しようとしているのか
-
「何に」しようとしているのか
⇧ 大まかに、3つの要素に分けることができ、
認可の関心を分離させるのは難しいのですが、ここで認可三大要素がポイントとなります。
- 「誰が」リクエストしているか（actor）
- 「何を」しようとしているのか（action）
- 「何に」しようとしているのか（resource）
このactor, action, resourceを使ってアプリ側のロジックとの関心の分離を試みます。
⇧ とありますと。
AWSのIAMの説明を見ると、
IAMの仕組み
IAM は、AWS アカウント の認証と認可を制御するために必要なインフラストラクチャを提供します。IAM のインフラストラクチャーは、次の図で示されています。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/intro-structure.html
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/intro-structure.html
次に、プリンシパルにリソースへのアクセスを許可するリクエストが行われます。アクセスは、承認リクエストに応じて許可されます。例えば、コンソールに初めてサインインしてコンソールのホームページを開いたときは、特定のサービスにアクセスしているわけではありません。サービスを選択すると、承認リクエストがそのサービスに送信され、ユーザーの ID が認証されたユーザーのリストに含まれているかどうか、付与されるアクセスレベルを制御するためにどのようなポリシーが適用されているか、そして、その他の有効なポリシーがないかが確認されます。承認リクエストは、AWS アカウント 内または信頼できる別の AWS アカウント プリンシパルが行うことができます。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/intro-structure.html
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/intro-structure.html
アクションの実行とリソースへのアクセスを行うためにポリシーで承認できる IAM リソース。IAM アイデンティティには、ユーザー、グループ、およびロールがあります。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/intro-structure.html
⇧ イメージし易いかもですが、基本的には、
- 誰が（Who）→ actor
- プリンシパル
- IAM ユーザー
- フェデレーションユーザー
- IAM ロール
- アプリケーション
- プリンシパル
- 何を（What）→ action
- アクション
- 何に（Whom）→ resource
- ユーザー内の AWS アカウント リソース
⇧ 「誰が（Who）」「何を（What）」「何に（Whom）」の3つの要素の組み合わせで権限を設計していく感じな考えは、似ている。
まずは、「要求定義」ないしは「要件定義」で「機能一覧」で機能の全量を洗い出して、「外部設計（基本設計）」で「データモデル」の詳細を整理したら、
- 誰が（Who）→ actor
- 何を（What）→ action
- 何に（Whom）→ resource
をマッピングしていく感じなんですかね？
なので、システムの機能を利用するユーザーの種類についても全量を洗い出す必要があると。
あとは、ユーザーに「状態」とかも持たせないといけないと思うので、
⇧ 上記サイト様のように、「user_状態」のようなテーブルを用意する感じになるんかな？
ただ、業務によっては複数の状態を持たせたいケースとかも出てくると思われ、
⇧ 上記サイト様にありますように、状態履歴テーブルを用意するパターンもあると。
「電子決済」のようにユーザーの状態が複雑になってくるとテーブル設計も難しくなってきますな...
「決済手段」毎の「利用不可」の条件が定かでないので、適当ですが、
| No | 決済手段 | 状態 | |
|---|---|---|---|
| 1 | クレジットカード | 利用可能 | |
| 2 | 利用不可 | カード未発行 | |
| 3 | 有効期限切れ | ||
| 4 | 支払不履行 | ||
| 5 | プリペイドカード | 利用可能 | |
| 6 | 利用不可 | カード未発行 | |
| 7 | 有効期限切れ | ||
| 8 | 支払不履行 | ||
| 9 | デビットカード | 利用可能 | |
| 10 | 利用不可 | カード未発行 | |
| 11 | 有効期限切れ | ||
| 12 | 支払不履行 | ||
| 13 | 電子マネー | 利用可能 | |
| 14 | 利用不可 | カード未発行 | |
| 15 | 有効期限切れ | ||
| 16 | 支払不履行 | ||
⇧ みたいな感じで、少なくともユーザーに関係する16の状態が有り得ると。
「コード」決済とかも絡んでくると、更に混沌としてきそうですな...
忘れてたけど、
⇧ このあたりのことも考え出すと、更に、意味の分からないことになってきそう...
Web APIの権限の設計については、一旦、「決済手段」の「利用可能」だけを考えて、進める感じにすれば良いんかな...
と言っても、
- ブラック
- プラチナ
- ゴールド
- 一般
の「ランク」も考慮する必要があると...
まぁ、でも、普通に「電子決済」する分には、「ランク」とかで考慮する点は、ユーザーが「年会費」の未払いがあるかどうかのチェックの必要性ぐらいしか思いつかない...
う～む、Web APIの権限の設計、難し過ぎるんだが...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
