Software Design 202310

ネットワークセキュリティ

基本

• ネットワークセキュリティとは防衛策のこと
  • for
    • 情報資産の保護
    • 安全運用の維持
• オープンネットワーク or クローズドネットワーク
  • 外部と繋がっているか、閉鎖されているかで対策は変わる

情報セキュリティの 3 要素 + 4 要素

すべての項目で対策が必要

主要	要素	英語での表現	説明
*	気密性	Confidentiality	アクセスが制限されている
*	完全性	Integrity	情報が書き換えられたり過不足があったりしない
*	可用性	Availability	必要な人がいつでも使えること
	真正性	Authenticity	本当にその人かどうか
	責任追及性	Accountability	誰が何をしたかを追跡できる
	否認防止	Non-repudiation	言い逃れを防げる
	信頼性	Reliability	何があっても変なことにならない

サイバーキルチェーン

攻撃者が攻撃を行うまでの一連の流れで、以下の 7 段階がある。

段階	名称	説明
1	偵察	ターゲットの調査を行う段階
2	武器化	マルウェアの選定 or 開発
3	デリバリー	マルウェアをターゲットに送り込む
4	エクスプロイト	マルウェアが実行される
5	インストール	マルウェアにより本丸のマルウェアがインストールされる
6	Command & Control	ターゲットのシステムを外部から遠隔操作する
7	目的実行	攻撃の目標を達成する

• 偵察の例
  • ポートスキャン
    • 動いているサービスを推測する
  • フィンガープリンティング、脆弱性スキャン
    • 特殊パケットを送り込み、その返信を分析して、OS やミドルウェアの種類やバージョンを特定する
• デリバリー・エクスプロイト・インストールの例
  • SQL インジェクション攻撃
  • XSS 攻撃
  • クロスサイトリクエストフォージェリ(CSRF)攻撃
    • 攻撃用の偽サイトを用意し、正規サイトに対してユーザーが意図していない操作を行わせる
  • ディレクトリトラバーサル攻撃
    • ディレクトリの階層を上がって、本来アクセスできないファイルを読み込む
  • DDoS 攻撃
  • ARP スプーフィング攻撃
    • ARP 応答を偽装することでユーザーからの通信を自分に向けさせる
  • セッションハイジャック攻撃
    • 前述の方法などによりセッション ID を盗み、その ID を使って攻撃を行う
    • 深刻な被害をもたらすため絶対に防がなければならない
• C&C の例
  • ボットやボットネットワークを使い、外部から遠隔操作を行う
  • ここまで来ると被害者は同時に加害者にもなりえる

対策

• 「ネットワーク層で多層のロジックを用いて監視すること」が基本
• 3 つに分けて対策する
  • 入口
    • メールフィルタリング
    • Firewall
    • IPS
    • WAF
    • サンドボックスの活用
  • 内部
    • ログ監視
    • データの暗号化
    • セキュリティソフト
    • EDR / Endpoint Detection and Response / エンドポイントの不審な挙動の検知
    • IDS / 不正侵入検知
  • 出口
    • Firewall
    • IPS
    • プロキシサーバによるフィルタリングやブロック

防御システム

ファイアウォール

• フィルタリングが本質
  • ステートフルパケットインスペクションにより戻りの通信を動的に許可できる
  • 事前定義したポリシーに沿って通信を制御する
  • 通信の中身までは見ない
• 種類
  • ゲートウェイ型ファイアウォール(外部との境界で動く)
  • パーソナルファイアウォール (個々の機器で動く)
• 防げる攻撃
  • ポートスキャン、フィンガープリンティング、脆弱性スキャン
  • 外部への悪意ある通信
• 防げない攻撃
  • 正常な通信の中に紛れ込んだ攻撃
    • e.g. SQL インジェクション、DDoS 攻撃

IPS / Intrusion Prevention System

• 全通信を許可した上で監視し、不正な通信があれば遮断する
  • ファイアウォールとは逆のアプローチ
• ネットワーク上位に配置して広く監視するケースが一般的
• 検知方法
  • シグネチャ型
    • 既知のパターンを登録しておき検知
    • 新しい攻撃に弱い
  • アノマリ型
    • 正常な通信を登録しておき、それ以外を異常として検知する
    • 誤検知が多い
• 設置方法
  • ゲートウェイ型 (全体を広く監視)
  • ホスト型 (機器ごと)
• 防げる攻撃
  • OS やミドルウェアの脆弱性を悪用する攻撃
  • DDoS 攻撃
• 防げない攻撃
  • Web アプリ固有の脆弱性
    • SQL インジェクション、XSS
    • 高度に難読化されている事が多く検知しにくい

IDS / Intrusion Detection System

• IDS は「不審」な動きを「検知 & 記録」する
  • 対して、IPS は「不正」な動きを「遮断」する
• 外部との通信のみならず、内部通信も監視できる
  • これにより、シャドー IT の検知や、インシデント後の復旧完了の根拠として使える
• その他の特徴は IPS とほぼ同じ

WAF

• L7 レイヤーを監視して怪しい通信を遮断する
  • Firewall といいつつ動きは IPS に近い
• Web アプリに特化しており、IPS より検出精度が高い
• HTTPS のデコードその他の対応が必要
• 検知方法
  • シグネチャ型
  • アノマリ型
• 設置方法
  • ゲートウェイ型
  • ホスト型
  • クラウド型
• 防げる攻撃
  • Web アプリ固有の脆弱性
    • SQL インジェクション、XSS、CSRF、ディレクトリトラバーサル
• 防げない攻撃
  • ネットワーク層への攻撃
  • OS、ミドルウェアへの攻撃

SASE

• Secure Access Service Edge / サシー
• 端末のアクセスを毎回、クラウドベースの SASE で監視・制御することで、ゼロトラストを実現する
  • クラウドサービスとして提供される
  • ネットワークの外は危険、中は安全という考えをやめる
• 構成要素
  • VPN
  • SD-WAN
  • Proxy
  • SWG / Secure Web Gateway
    • 不審な Web サイトへの接続や危険なファイルのダウンロードを防ぐ
  • CASB / Cloud Access Security Broker
    • 各種クラウドサービスの利用状況を可視化/制御する
  • ZTNA / Zero Trust Network Access
    • 利用者や端末の状態を都度確認し、アクセスを制御する
  • FWaaS / Firewall as a Service
  • XDR / Extended Detection and Response
    • 攻撃の痕跡を検知・可視化することで、インシデントの調査・原因特定・対処を行う機能

VPN と暗号化

VPN

• VPN とは
  • 複数の拠点間で仮想の専用回線を構築するための仕組み
  • 本物の専用回線を借りるより安価
• 特徴
  • トンネリング / 仮想通路により、外部からの盗聴を防ぐ
  • カプセル化 / 独自のプロトコルで通信を行う
  • 暗号化 / 通信内容を暗号化する
  • 認証 / 通信相手の認証を行う
• 種類
  • IP-VPN
    • 通信事業者が独自に保有する閉域 NW を利用して構築する
    • 暗号化は行わないことが多い
    • 高価
  • インターネット VPN
    • インターネットを利用して構築する
    • 暗号化が必須
    • 安価
• メリット
  • リモート or モバイルから社内 NW にアクセスできる
  • 一定レベルのセキュリティを担保できる
  • 専用線より安い
  • 柔軟に複数の拠点間で通信を行える
    • 専用線だと支社間の通信まではしないので
• リスク
  • 正規の認証情報が漏れて外部からアクセスされる
  • 機器の脆弱性により外部からアクセスされる
• セキュリティ対策
  • 最新のファームウェア等適用
  • 前段に IPS を設置
  • VPN の認証に多要素認証を導入
  • 通信の監視

暗号化

• 共通鍵暗号方式
  • 送信者と受信者が、暗号化と復号で同じ鍵を共有する
  • 鍵を秘密裏に共有する必要がある
  • 暗号化する経路の数だけ鍵が必要
  • 代表的なアルゴリズム
    • DES / 3DES / アメリカ政府の旧標準、いずれもオワコン
    • AES / アメリカ政府の新標準、DES の後継
• 公開鍵暗号方式
  • 送信者と受信者が、秘密鍵と公開鍵の異なる 2 つの鍵を持つ
  • お互いに公開鍵だけを共有すればいいので、安全に鍵を共有できる
  • 2 通りの暗号化
    • 公開鍵で暗号化したものは、秘密鍵でしか復号できない
      • メインのユースケースで、データの安全な通信のために使われる
    • 秘密鍵で暗号化したものは、公開鍵でしか復号できない
      • サブのユースケースで、本人証明のために使われる
  • 代表的なアルゴリズム
    • RSA
      • 2048 ビットが推奨されている
      • 共通鍵暗号方式よりも遅い
• ハッシュ化
  • 一方向性の暗号化
  • 同じデータからは必ず同じハッシュが生成される
  • セキュリティ対策
    • 適切なアルゴリズムの選択
    • ソルトの付与 (レインボーテーブル対策)
    • ハッシュ化の繰り返し
  • 代表的なアルゴリズム
    • MD5 / SHA-1 / いずれもオワコン
    • SHA-2 / 256 ビット以上がアメリカ政府の新標準
• デジタル署名
  • 本人であることと、データの改ざんがないことを証明する
  • 前述の秘密鍵での暗号化と、ハッシュ化を組み合わせて行う

認証

• 以下のうち 2 つの要素を組み合わせることが重要
  • 知識要素
    • 本人だけが知っている情報
    • パスワード、秘密の質問
  • 所持要素
    • 本人が持っているもの
    • IC カード、秘密鍵、TOTP
  • 生体要素
    • 本人の身体的な情報
    • 指紋、顔、静脈
• 2 要素認証と 2 段階認証
  • パスワード+秘密の認証は 1 つしか要素がないので 2 段階認証
  • パスキーは秘密鍵+生体要素なので 2 要素認証
  • TOTP はパスワード+所持要素なので 2 要素認証
• PKI / 公開鍵基盤
  • 公開鍵の真正性を第三者機関の認証局(CA: Certified Authority)が保証する仕組み
  • CA はデジタル証明書をデジタル署名付きで発行する
    • 証明書は公開鍵、身元情報、有効期限、その他の関連情報を含む
• ワンタイムパスワード
  • チャレンジレスポンス方式 / 直接パスワードを送信しないで済む仕組み
  • トークン / TOTP、キーホルダーほか
• シングルサインオン
  • 方式
    • エージェント型
      • 全てのサーバーにエージェントをインストールする方式
    • リバースプロキシ型
      • ユーザーと Web アプリの間に 1 台のリバースプロキシを置く方式
  • いずれの方法も、ユーザーと Web アプリの通信の間に割り込み、ユーザの情報を HTTP リクエストに付与して、アプリに連携する

クラウドセキュリティーネットワーク

• IaaS
  • 必要なセキュリティ対策はオンプレとほぼ同じ
  • 不正通信対策と脆弱性対策(IPS, IDS, WAF...)
• CaaS
  • コンテナ特有のライフサイクルを踏まえた対策が必要
    • 安全なコンテナイメージの利用
    • コンテナレジストリの保護
    • オーケストレーションツール(e.g. Kubernetes)の保護
    • アプリケーション、ネットワークの保護
      • ホスト単位ではなく、アプリケーション単位での保護が効果的
    • コンテナホストの保護
      • e.g. ECS の EC2 タイプ
    • ビルドパイプラインの保護
      • Jenkins 等の最新化

HTTP/3

HTTP の歴史

• HTTP/0.9
  • 1991 年に登場
  • GET と URI のみ
• HTTP/1.0
  • 1992 年から策定開始
  • RFC1945
  • 変更点
    • ヘッダフィールドの追加
    • HEAD, POST メソッドの追加
    • ステータスコードの追加
  • 毎回 3-way handshake で効率悪し
• HTTP/1.1
  • 1997 年に発行
  • RFC2068 / RFC2616
  • 変更点
    • Connection や Keep-Alive ヘッダの追加
      • TCP コネクションの使い回しが可能に
    • ネゴシエーションのためのヘッダフィールドの追加
      • Accept-Charset, Accept-Encoding, Accept-Language など
    • Host ヘッダがデフォルトで付与に
      • バーチャルホストが可能に
  • 表示速度の問題
    • Head-of−Line Blocking
      • 1 つの TCP コネクションでは、リクエストした順番でしかレスポンスを受け取れない
    • かといって TCP コネクションを多重化する試みは諸々の理由でうまく行かなかった
• HTTP/2
  • 2015 年に発行
  • RFC7540
  • 変更点
    • ストリームによる多重化
      • 1 つの TCP コネクションの中で複数のリクエストを並列に扱うことで高速化する
    • 優先度制御
      • リクエストに優先度をつけて送信できる
    • フロー制御
      • 受信可能なデータサイズを送信側に通知してオーバーフローを防ぐ
    • ヘッダ圧縮
      • ヘッダフィールドを圧縮して送信する
      • HPACK という効率的なしくみ
    • 疑似ヘッダフィールド
      • コロンがついたヘッダフィールドにメソッド等をかけるようになった
      • :method, :scheme, :authority, :path など
      • ヘッダ圧縮の対象にして高速化するため
  • 課題
    • 優先度制御が難しく、ブラウザにより実装が様々
    • HTTP レイヤの HOL Blocking は解消したが TCP レイヤでは残存
      • 常にパケットロスがあるような低品質 NW で発生
    • プロトコル硬直化
      • 古いプロトコルしか知らない中継機器が勝手にパケットを捨てちゃう
• HTTP/3
  • 2022 年発行
  • RFC 9114
  • 変更点 (詳細は本文の図がわかりやすい)
    • TCP から UDP に
      • TCP レイヤでの HOL Blocking を解消
      • UDP は低機能だが、不足部分は QUIC が巻き取った
    • QUIC プロトコルの採用
      • 従来ほかのレイヤが担っていた役割を引き受けた
        • TCP レイヤでやっていたコネクション管理
        • HTTP/2 レイヤでやっていたストリーム多重化
        • TLS レイヤの内包
      • カーネルではなくユーザスペースでの実装に
        • e.g. Chrome 内に実装される
        • プロトコルのアップデートが容易に
    • 暗号化が必須に
      • プロトコル硬直化を解消
    • 優先度制御がシンプルに
    • ハンドシェイクが 1-RTT or 0-RTT で完了するように
    • コネクションマイグレーションが可能に
      • コネクションごとに ID を持っており、5 タプルが変わっても接続を維持できる
      • 5 タプルとは [プロトコル、送信元IP、送信元ポート、送信先IP、送信先ポート]
    • ヘッダ圧縮の仕様が HPACK から QPACK に
      • フレーム到着順の制約がなくなった
  • 使い所
    • 通信環境の悪いモバイルには最適
    • データセンターには不適
      • ユーザースペースでの実装のため、超ハイパフォーマンス環境では不利
  • 備考
    • UDP の 443 番ポートの開放が必要

HTTP/3 のしくみ

• サーバがブラウザ側に HTTP/3 の利用可否を知らせる方法
  • Alt-Svc ヘッダで知らせる方法
    • RFC7838
    • HTTP レスポンスヘッダに可能な接続情報ほかを記述する
    • 初回の接続時には情報がないという欠点がある
  • DNS の HTTPS リソースレコードで知らせる方法
    • 同じく RFC7838
    • DNS レコードに情報を記載する
    • 接続前に知ることができるが、DNS サービスによっては利用できないので Alt-Svc と併用が吉

実践

• 使い始めるには
  • CDN を利用するのが主流
  • 設定一つで利用開始できる場合も
• 対応しているクライアント
  • 2023/08 時点では、ほぼブラウザのみ

Go 言語のエラー処理 (前編)

• 原則は"Errores are value. Don't panic."
• Go では、異常系を通常発生するものととらえ、その際に出てきたエラー変数の処理の仕方は開発者がきちんと責任を持って考えるべきだ、という思想になっている
• 「エラーは値である」というのが基本的な考え方
  • 値であるがゆえに、エラーを使った柔軟なプログラミングが可能
• try / catch がない理由
  • ネストを浅く保つことで、正常系の処理を視覚的に明確にするため
  • 発生するエラーがきちんと処理されているか明確にするため
  • どこで関数が return されているか明確にするため
• panic はエラー処理に使うものではない
  • 起こってはならない回復不可能な事象に使うもの
    • 初期化段階での致命的な失敗や、nil 参照など
• recover の使いどころ
  • ごく一部の失敗でプログラム全体が終了するのを防ぐために使う。例えば：
    • Web サーバーの一部のリクエストでエラーが発生しても、他のリクエストは処理を続ける、とか
    • 一つのゴルーチンで panic が発生しても、他のゴルーチンは処理を続ける、とか

AWS Security Hub

• Cloud Security Posture(心構え) Management Service
• 設定や設計の誤りによるセキュリティリスクを検出する
• 5 つのセキュリティ基準があるので、最適なものを選択する
• 重要度 / 緊急・高・中・低
• 間隔 / 定期・設定変更時

IAM ユーザーと認証情報のベストプラクティス

• IAM ユーザーの 3 大ユースケースは以下だが、いずれも IAM ユーザーを使う必要はない
  • IAM ユーザーのアクセスキーを CLI の認証情報として使い、AWS にアクセスする
    • 「ID プロバイダーを利用したフェデレーション」を使え
  • IAM ユーザーのアクセスキーを SDK の認証情報として使い、AWS にアクセスする
    • IAM ロールを使え
  • マネコンにログインする
    • 「ID プロバイダーを利用したフェデレーション」を使え
• SAML ベースのフェデレーション
  • AWS ログイン時に Google アカウントでログインしたら AWS が使えるようになるやつ
  • 裏では Google から AWS に Security Assertion Markup Language(SAML)で認証情報を渡している