darallium's tech blog

  • 第44回sosailtに行ってきた話

    第44回sosaiLT 聴講メモ

    開催概要

    第44回sosailtに参加してきました。 大変勉強になりました。ありがとうございました。

    第1講演: 上原哲太郎先生「パスワードレス」

    1. 背景と現状の問題点

    • サイバー攻撃の増加: 近年、サイバー攻撃が増加しており、特にアカウント窃取の被害が深刻化している。
    • 対策の普及: MFA（多要素認証）やパスワードレス認証が普及しつつある。
    • 認証の複雑化による弊害:
      • ユーザーにとって「何をしているかわからない」認証が増加。
      • 結果として、ユーザー教育を無視した認証システムが増えている。
      • 「本人確認」と「ユーザー認証」が混同されているケースが見られる。

    2. 基本的な概念

    • ユーザー認証:
      • 定義: アカウント（ID）の所有者が正当であるかどうかを検証する仕組み。
      • IDの要件:
        • IDは全体でユニークである必要がある。
        • 一人の人間が複数のIDを所有するのは許可されるが、その逆（複数の人間が一つのIDを共有する）は禁止。
    • 本人確認:
      • 定義: IDがどの自然人に対応づくかを確認する行為。
      • レベル分け (NIST SP 800-63-3 Level of Assurance - LoA):
        • 本人確認レベル (IAL):
          • IAL1: 自己申告
          • IAL2: リモートまたは対面での確認
          • IAL3: 対面での厳格な確認

    3. 認証要素とパスワード

    • 認証要素3種類: 「記憶による認証（パスワードなど）」「所有による認証（トークン、スマートフォンなど）」「生体認証（指紋、顔など）」のうち、2つ以上を用いることが推奨される（MFA）。
      • しかし、運用が難しい側面もある。
    • パスワードの課題:
      • 理想と現実: 複雑で長く、推測困難なものが理想とされるが、ユーザーが覚えるのは現実的ではない。
        • 例: 英数字記号8文字の組み合わせ（約60種類）よりも、中学生レベルの英単語（約2500語）を組み合わせた方が、短く覚えやすい場合がある。
      • オンライン総当たり攻撃への誤解:
        • ログインフォームへのオンライン総当たり攻撃は、システム側の対策（アカウントロックなど）があれば現実的ではない。もし可能であれば、それはシステム側の不備。
      • 真のリスク: Hash漏洩時など、オフラインで解析可能な攻撃の方がはるかにリスクが大きい。これを防ぐには、パスワードの組み合わせを十分に発散させる（長く、複雑にする）必要がある。

    4. フィッシング対策

    • **現状:**巧妙化しており、見た目だけで怪しいサイトを見分けるのは困難。
    • 対策: URLを注意深く確認し、正当なサイトであるかを検証する必要がある。
    • 発生要因: 多くはメール経由であり、メールで送信されたURLには特に注意が必要。

    5. パスワードの旧プラクティス（ランク分け）

    1. 超重要 (MS/Googleアカウントなど): できるだけ複雑で長いものにする。ただし、強要しすぎない。
    2. 重要: ランダムな文字列を基本とし、サイトごとに数文字変更する。
    3. その他 (どうでもよいサイト): できるだけ複雑なものにしておき、忘れても問題ないようにする（パスワードマネージャー利用など）。

    6. MFAの課題と留意点

    • 記憶以外の要素の必要性: 単なる記憶だけに頼らない認証が求められる。
    • 生体認証の過信禁物:
      • 安易な生体認証の導入は推奨されない。
      • 生体認証は確率的な認証であり、オフライン環境での利用には本質的に向かない。
    • お手軽なOOB (Out-of-Band) TOTP (Time-based One-Time Password):
      • 回線（電話番号）、メールアドレス、SMSなどを「所有」していることを基盤に認証する。
      • フィッシング攻撃に対して脆弱な場合がある。

    7. FIDO (Fast IDentity Online)

    • 目的: 生体認証とデバイス認証（危機認証）を組み合わせ、パスワード不要の認証を目指す規格。
    • 期待: 実現できれば非常に優れた認証方式となる。

    8. Passkey

    • 構成要素: WebAuthn + FIDO2 + 認証キーストア
    • 重要な仕組み: Microsoft、Google、Appleが共同で「公開鍵に対応する電子署名を預かる」仕組み。
    • 画期的な点: 一つのIDに対して複数の認証要素を紐付け可能にする。
    • 課題:
      • Apple、Google、MicrosoftがPasskeyのキーストアをそれぞれ囲い込んでいる。
      • 結果として、プラットフォームごとにわずかに異なる認証方式が利用されている。
      • 「所有認証」のはずが、ユーザーにとって何を所有しているのかが分かりにくい場合がある。

    第1LT

    • 非公開

    第2LT: プログラム著作権の話

    • テーマ: プログラムの著作権は、争われると非常に複雑で面倒な問題となる。
    • プログラムの著作物性:
      • 定義 (著作権法): 「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」をいう。
      • ポイント:
        • 著作権が発生するのは、プログラムの機能そのものではなく、コードの表現における工夫（創意工夫性）。
        • 実現される機能は特許の対象。
        • 例: 独創的なワンライナーなど。
    • 判断の難しさ:
      • コードの創造性を判断するにはソースコードの分析が必須。
      • 裁判官が技術的な判断をすることは難しい場合が多い。
    • 考察 (Haskellと数学構造):
      • プログラミング言語Haskellでは、関数型プログラミングの考え方から、プログラムと数学的構造が同型と捉えられることがある（例: ラムダ計算は万能性を持つ）。
      • 数学の証明自体には著作権が認められないのと同様に、プログラムのロジック部分にも著作権が認められないのではないか、という疑問。

    第3LT: ネットワークだけ隔離されたコンテナ作成

    • コンテナの基本: 隔離されたプロセス。Namespace技術を利用して隔離を実現。
    • ネットワーク隔離コンテナの仕組み:
      • コンテナのNIC（ネットワークインターフェースカード）は仮想的にペアで作成される。
      • このペアを2組作成し、L2トンネリング技術を用いることで、コンテナを外部ネットワークと通信させることが可能になる。
    • デモ: https://asciinema.org/a/665211

    第4LT: sosaiLTでNWハンズオンをやった話

    • 内容:
      • 初心者向けのネットワーク基礎座学
      • Windowsでの固定IPアドレス設定
      • ネットワーク障害の原因切り分け演習
    • ハンズオンの工夫:
      • 伝言ゲーム形式の説明:
        • 通路の一番近くの人に説明し、その人に奥へ伝えてもらう方式。
        • 「遠くに伝える」＝「詳しそうな人にお願いする」というアナロジーで設定作業を説明。
        • 「廊下に立っている人」をゲートウェイに例える。
      • 障害切り分け演習:
        • pingなどのトラブルシューティングツールの紹介。
        • 実際に障害を発生させて体験。
        • tracert www.sosai-lt.internal を用いた経路調査。
        • DNS障害を意図的に起こし、NW通信への影響を体験。
    • 準備:
      • 資料は80枚、所要時間は約3時間。
      • 物理配線が大変だった。

    第5LT: beta/beta’モデルによる外部監査

    • 自治体情報セキュリティモデル:
      • betaモデル: インターネット接続系に業務端末を配置。入札情報や職員の個人情報など重要な資産はLGWAN系に配置。
      • beta’モデル (ベータダッシュモデル): 三層分離のうち、職員の情報なども一部インターネット接続系に置くことを許容するモデル。
      • alpha’モデル (アルファダッシュモデル): Web会議などを利用するため、ローカルブレイクアウトを導入するためのモデル。
    • 外部監査の目的: beta/beta’モデルが正しく構築され、適切に運用されているかを確認する。

    技術的対策の監査と実態

    • 監査項目上の対策:
      • 多くはベンダーによって対応済みであり、監査項目上は問題ないことが多い。
    • 監査項目外だが構造的に懸念される点:
      • EDR (Endpoint Detection and Response):
        • 即時遮断できない設定のものがある。
        • SoC (Security Operation Center) の監視が甘く、ホワイトリスト運用に寄りすぎている場合がある。
        • インシデント対応が侵害発生後からの対応になっている。
      • AD (Active Directory) 運用:
        • 運用スキルが未熟な場合がある。
        • グループポリシーの知識はあるものの、パスワードポリシーやスクリーンセーバーロックの設定などが不十分。
      • ACL (Access Control List):
        • 設定はされているが、システマティックな運用ではなく、人手による運用に頼っているように見える。
      • アップデート管理:
        • PCのアップデートは実施されているが、NAS（Network Attached Storage）やネットワーク機器のファームウェアアップデートは疎かになりがち。
      • セキュリティ教育:
        • 問題点: 課長職以上がセキュリティ教育を免除されているケースがある (非常に問題)。
    ===============広告=================

    darallium

    Mon Oct 07 2024 15:55:50 GMT+0900 (Japan Standard Time)