ID基盤で知っておきたい、抑えてお きたいセキュリティの話

自己紹介 ● 林　吟志 (Ginji Hayashi) ● ● Now フリーランス。 IT/セキュリティ エンジニア ○ https://www.gihayash.work/ ○ https://www.linkedin.com/in/ginji/ ○ ● 2021 - 2023 @ メルカリ as Security Engineer ○ Corporate IT Security ○ ● 2020 - 2021 @ 日本マイクロソフト As Customer Support Engineer ○ 自社ソリューションの Premier/Unifiedカスタマーサポート エンジニア ○ ● 2019-2020 @ NRIセキュアテクノロジーズ As Security Consultant ○ マネージドEDRサービスの開発、お客様向け導入コンサルティング ○ ● 2011-2019 @ NRIセキュアテクノロジーズ As Security Analyst ○ お客様向けセキュアインターネット接続サービス、リモートアクセスサービスの運用・維持管理、および導 入提案、導入 ベンダ・メーカ・ユーザ、異なる視点から IT/Securityに関わってきました。 10分という短い時間ですが、どうぞよろしくお願いします。 2

認証・認可の違い ● 認証(AuthN)とは「あなたは誰ですか？」 を確認すること。 ○ 私は Ginji Hayashi です。 ○ 指紋・顔認証（Who I am）・免許証の提示（What I have）・パスワードの回答（ What I know） ● 認可(AuthZ)とは「私はアクセスする権限があるか？」を確認すること。 ○ よし、この画面にアクセスして良い /このサイトにはアクセス出来ない。 ● 認証と認可は同じタイミングで行われることも多く混同しがちだが、 異なる概念なので混ぜると危険。 パスポートを交通会館で発行する その人として日本国から認証される。 入管にパスポートを見せて入国する 認証情報を利用して、入国が 認可される。 3

なぜ認証が重要視されるのか。 （出典）BeyondCorp　A New Approach to Enterprise Security https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/43231.pdf 4 ● ゼロトラストモデルで援用される有名なモデル図 ● アクセス制御の判断において、まずは認証が1丁目1番地。

認証方式は思い込みで実装してはいけない ● まずはパスワード。複雑性、長さなどセキュリティに関するポリシー ○ CIS Password Policy Guide ○ NIST SP800-63 ○ 会社・組織のポリシー、業界のポリシー (PCI DSSやHIPPAなど) ○ などなど ● ● 独自の経験や勘所ではなく、拠り所となるポリシーを選択・参照し自組織に適用す ること。 ○ ポリシーや技術は日々アップデートされる。最新の動向を抑えておくこと。 ○ パスワードの定期的な更新運用はストレスとなり、簡単なパスワードにしてしまう ○ 秘密の質問は非常に推測されやすく、現在においては非推奨 ○ 有効パスワード長は Compute Resourceの進化により、安全圏が変化する 5

認証器による要素の分類 6 知識 (What I Know) 所有 (What I Have) 生体 (What I am) ● パスワード ● PINコード ● 秘密の質問 ● SMS ● TOTP(Google Authenticator など) ● マジックリンク ● タッチ yubikey (OTP) ● バイオメトリクス認証 ● Touch ID ● Windows Hello(顔認証や指紋 認証) ● 認証要素は知識・所有・生体に大別され、要素の組み合わせで多要素認証となる ● 同一要素を複数求めることは時間稼ぎにはなるが、セキュリティレベルは向上しない ● 認証のレベル　Authenticator Assurance Level（AAL） NIST SP800-63B ○ 登録済みユーザーがログインする際の認証プロセスの強度 ○ Lv.1 ：単要素認証でOK ○ Lv.2 ：2要素認証が必要、2要素目の認証手段はソフトウェアベースのもので OK ○ Lv.3 ：2要素認証が必要、かつ2要素目の認証手段はハードウェアトークン等

認証器による要素の分類 7 ユーザーの存在 デバイスとの紐づき フィッシング耐性 ハードウェアによる保護 メール、SMS ◯ ー ー ー パスワード/秘密の質問 ◯ ー ー ー Google Authenticator ◯ △ ー ー Yubikey OTP ◯ ◯ ー ◯ WebAuthn (Security Key/生体) ◯ ◯ ◯ ー ● 認証要素を選択する際は、各要素により実現できる事、出来ないことを明確にしておくことが 重要。 ● UXを毀損させないため、アクセスに応じて認証強度を変えるのは効果的。 （出典）Okta Docs (Multifactor authentication) https://help.okta.com/oie/en-us/content/topics/identity-engine/authenticators/about-authenticators.htm

セキュリティのトレンド、原則　ーセキュリティバイデザインー ● 従来の開発プロセスでは、完成した後のセキュリティ診断や、運用におけるセキュ リティを重視していた。 ● セキュリティを実装や運用フェーズで対策すると、高コストになる。 ● セキュリティを仕様検討・設計の早い段階から組み込んでいく原則。 (出典）プラクティス 5-3　セキュリティバイデザインを標準とする、クラウドベースの開発プロセスの励行 https://www.ipa.go.jp/security/economics/practice/practices/Practice214/ 8

セキュリティのトレンド、原則　ーセキュリティバイデフォルトー ● そもそも、ユーザーが意識しなくとも安全であるべきでは？ ● ユーザーがセキュリティを高めようとあれこれせず、何もせずともセキュリティが高 い状態にする原則。 ● ● もし悪い状態に変更しても、後から追跡できるようにする事が重要。認証ログ、監査 ログはちゃんと取れているか？ ● 利便性とセキュリティが衝突することは、当然ありうる。 (出典）Secure by Default https://www.ncsc.gov.uk/information/secure-default 9

まとめ ● 認証認可の違い、なぜ認証は大切なのか ● ● 認証に関するポリシーや認証要素の分類 ● ● セキュリティの原則 10

ご清聴ありがとうございました。 11 https://www.gihayash.work/ https://www.linkedin.com/in/ginji/