フレネル反射（Fresnel Reflectance）

この映像は、青い球体が中央に浮かび、その縁が角度によって白く輝いて見えるという、ガラス玉のようなリアルな印象を与えます。これは**フレネル反射（Fresnel Reflectance）**という技法によって実現されています。フレネル反射とは、物体の表面に対して見る角度が浅くなるほど、より多くの光が反射されて白っぽく見えるという、現実の光の性質を再現する手法です。たとえば水面を真上から見ると透明でも、斜めから見ると白く反射するような現象と同じです。この視線と表面のなす角を「内積」という計算で求め、それをもとに色の混ざり具合を決めています。球体の輪郭が白く光って見えるのは、この内積の値をもとに、中心の青と縁の白を段階的に混ぜているからです。混ぜる割合は、距離や角度によって変化し、自然なグラデーションを生み出します。これにより、物体の立体感や透明感が強調され、見る者にリアルで物理的な存在感を感じさせるのです。このような効果は、変数名ではnormal（表面の向き）とviewDir（視線の向き）、そしてそれらのdot（内積）によって計算され、fresnelという変数にその強さが保存されています。その後、mixという関数で基本色と反射の色が滑らかに合成され、最終的な色となって表示されます。こうした工程がすべて1フレームごとに計算されており、視点や時間に応じて連続的に変化します。このように、数式だけで物理的な印象を視覚的に再現できるのがGLSLの大きな魅力です。

パブリックドメイン（自由に利用可）の「アトラス」作品

パブリックドメイン（自由に利用可）の「アトラス」作品があります。高解像度でダウンロードできる代表例を挙げます。

• ジョン・シンガー・サージェント《アトラスとヘスペリデス》（1922–25）— ボストン美術館のオープンアクセス作品。所蔵ページから高解像度画像を取得できます。 MFA Collections+1

• グエルチーノ《天球を支えるアトラス》（1646）— ウィキメディア・コモンズに公有（PD）として掲載。大きな画像がそのまま利用できます。 Wikimedia Commons

• ルーカス・クラナハ（父）《ヘラクレスがアトラスを解放》（c.1530）— 米国ナショナル・ギャラリー（NGA）のオープンアクセス。ダウンロード可・公有。 nga.gov

• エドワード・バーン＝ジョーンズ《石に変えられたアトラス》（1878）— コモンズで公有として公開。大画像あり。 Wikimedia Commons

• ベルナール・ピカール工房《天を支えるアトラス》（1731）— アムステルダム国立美術館（Rijksmuseum）所蔵、Public Domain Mark 1.0。 Google Arts & Culture

あわせて、メトロポリタン美術館の「Open Access」で“Atlas”を検索すると、自由利用できる関連版画・素描が多数見つかります。 The Metropolitan Museum of Art

NDR／EDR／NGFW連携

 

1. MITRE ATT&CKで検知マップ作成（Execution/C2に厚め）

• 優先テクニック（例）：

  • T1059 Command & Scripting Interpreter（PowerShell/WSH/ bash）

  • T1071 Application Layer Protocol（HTTP(S)/DNS/メール等でのC2）

  • T1078 Valid Accounts（正当アカウント悪用）
    まずはこの3本柱を“必須検知”として赤塗り→データソース紐付け（EDR/NDR/AD/メール/プロキシ/Firewallログ）。 MITRE ATT&CK+2MITRE ATT&CK+2

• 最低限のイベント指標

• EDR：Office系→powershell/wscript/spawn、暗号化/エンコード引数、LOLBin（rundll32/regsvr32/mshta等）

• NDR：低スループット周期ビーコン、JA3/JA4異常、DNS/DoHトンネル徴候、長寿命TLS、SNI不整合

• NGFW/Proxy：新規/低評点FQDN、国際移動直後のVPN、未分類アプリ通信
  実際に2023年の大規模ネット観測でもC2と実行アクティビティが突出しており、優先領域として妥当です。 ホワイトペーパー ダウンロードセンター

• NDR⇄EDR⇄NGFW 連携運用の整備

• 相互トリガー（Playbook例）

  • NDR高確度C2検知 → EDR APIで端末隔離 → NGFWへ宛先FQDN/IPを動的アドレスグループに投入して遮断

  • EDR実行系高リスク（T1059） → NDRへ当該端点のフロー抽出要求 → NGFWへ“ユーザ/端点タグ”で送信遮断

  • NGFW脅威ログ（新規C2カテゴリ）→ EDRにコンテキスト送付しプロセスツリー自動調査

• 役割分担：NDR＝横展開/ネット痕跡、EDR＝端点の真偽判定と隔離、NGFW＝即時封じ込めの境界実施。EDRとNDRは補完関係で“両輪運用”が推奨。 ITmedia

• 回避技術への備え：近年は“EDR回避”手口が台頭→ネット側（NDR/NGFW）からも押さえる二重化が有効。 ITmedia

3. 正当アカウント悪用の監査強化（T1078）

• クラウド/SSO：異常サインイン（Impossible Travel/新端末/高リスクIP）、新規OAuth同意、MFA再登録、特権ロール付与を日次レビュー

• オンプレ/AD：イベントID 4624/4625（ログオン/失敗）、4768/4769（Kerberos）、4728/4729（特権グループ変更）を相関

• ポリシー：全アカウントにMFA、休眠/共有/デフォルト口座の廃止、緊急用Break-glassの保護。T1078の一次対策はMFA徹底です。 MITRE ATT&CKCenter for Threat-Informed Defense

• XDR/自動化：SOARまたはXDRで上記プレイブックを標準化（隔離・ブロック・証跡保全を“ワンクリック/自動”）。MITRE CoAの参照プレイブック（T1059/T1071/T1078）を雛形に。 Cortex XSOAR+2Cortex XSOAR+2

• 検証計画：T1059/T1071/T1078のレッドテスト（安全なシミュレーション）→検知率とMTTD/MTTRを測定し閾値調整。

• ダッシュボード：C2疑いの新規FQDN件数、周期ビーコン件数、実行系高リスク検知、正当アカウント異常の週次トレンドを可視化。

• 網羅化：横展開用にLateral Movement（T1021/SMB/RDP・Pass-the-Hash 等）とPersistence（T1053 タスク登録等）を追加。

• サプライチェーン/メール：T1566（フィッシング）→メール/代理送信・DMARC失敗の相関をNDR・EDRと接続。

• 運用標準：RACI（SOC/ネット/端末/ID管理）、保全・復旧・再発防止の3文書テンプレを完成。

---

参考（一次情報）

• 11兆超イベント分析とC2/実行の多発（ITmedia/TechTarget）—今回の優先度設定の根拠。 ホワイトペーパー ダウンロードセンター

• EDR×NDRの補完関係（ITmedia News）。 ITmedia

• EDR回避トレンド（ITmedia エンタープライズ）。 ITmedia

• MITRE ATT&CK：T1059 / T1071 / T1078 定義と対策の整理。 MITRE ATT&CK+2MITRE ATT&CK+2

多要素認証

 

1. FIDO2／パスキー採用：まず管理者・特権ロールをフィッシング耐性MFA（FIDO2／パスキー）に統一、順次全社へ展開。NIST案でもAAL2で“フィッシング耐性オプション”提供が求められています。pages.nist.gov

2. 未管理端末の遮断／制限：条件付きアクセスやコンテキストアウェアアクセスで「準拠端末のみフルアクセス」「未管理はWeb限定・DL禁止」などを実装。Microsoft Learn+1Google Help

3. プッシュ疲れ対策：**番号一致（Number Matching／Number Challenge）**を必須化し、プッシュ許可の地理情報・アプリ名表示も有効化。Microsoft Learnhelp.okta.com

4. レガシー認証の無効化（SMTP AUTH等）とVPN/VDI/SSOのMFA必須。CISA

5. 緊急用（ブレークグラス）アカウントと登録回復手順の整備。標的型のMFA疲労・ヘルプデスク狙い（Scattered Spider型）を前提に運用設計。TechRadar

設定のヒント

• Microsoft Entra：認証強度で「パスキー(FIDO2)」を有効化 → 対象ユーザー／アプリへ段階適用。条件付きアクセスで「準拠端末必須」「リスク高はブロック/強化MFA」を設定。Microsoft Learn+2Microsoft Learn+2

• Google Workspace：Context-Aware Accessで端末健全性／場所／IPに基づくきめ細かい制御を設定。Google Help

指標（ダッシュボード化）

• パスキー利用率（特権ユーザー→全社）／MFA方式別比率（FIDO2>アプリTOTP>SMS）。NIST/CISAは“フィッシング耐性MFA”を推奨・要求。pages.nist.govCISA

• 未管理端末からのブロック件数／制限付きセッション比率。Microsoft Learn

• MFAプッシュ誤承認率／番号一致未実装ユーザー数。Microsoft Learn

ロールアウト順（例）

• 0–30日：特権ロールをFIDO2へ、番号一致を強制、レガシー認証を棚卸し。Microsoft LearnCISA

• 31–60日：端末準拠ポリシー／BYOD方針を適用、未管理は制限付き。Microsoft Learn+1

• 61–90日：一般ユーザーへパスキー拡大（国内でも採用拡大中）。WealthNavi

補足

• FIDOアライアンスのガイダンスを参照（同期型パスキー／デバイス固定キーの使い分け）。FIDO Alliance

• ITmedia資料（8/26）はMFAの見直し点や運用ノウハウの整理に有用です（会員閲覧）。ホワイトペーパー ダウンロードセンター

ランサムウェア対策：企業がまずやる3つの実務（RDPゼロ・東西監視・自動隔離）とKPI

 

ランサムウェアは「入口防御の穴」と「横移動の見逃し」、そして「復旧の遅れ」が重なったときに甚大化します。CISAの#StopRansomwareやNISTのランサムウェアRMは、外部公開RDPの廃止とフィッシング耐性MFA、東西トラフィックの可視化、侵入後の即時隔離、そして定期的な復旧訓練を共通の骨子としています。本稿はその骨子に沿って、①攻撃面の削減 ②東西監視 ③侵入後の封じ込めに分け、すぐ回せるKPIと実運用で詰まりやすい点を具体的に示します（一次資料の根拠を併記）。CISANIST Publications

① 脆弱端点の削減（Attack Surface）

• 資産台帳を自動化し、未管理端末はNAC/MDMで遮断（“未管理=0”をKPI）。

• 外部公開RDP/SMB/SSHはゼロ。どうしても必要ならVPN＋フィッシング耐性MFA（パスキー/AAL2）を必須化。NIST

• 高危険パッチSLA：重大7日以内、ゼロデイは24時間以内。

• ローカル管理者権限を廃止、PAMでRMM/特権ツールを保護（最近RMM特権狙いのフィッシング増加）。ITmedia

② 東西トラフィック検査（Detect/Inspect）

• データセンター/仮想基盤にNDRセンサー（SPAN/TAP）、DNS/HTTP/SMB/TLSの可視化。

• 重要ゾーンはマイクロセグメント化し、横移動の振る舞い検知を有効化。

• CISAのStopRansomware推奨に沿って多層のDefense-in-Depthで監視点を増やす。CISA

③ 侵入後検知と隔離（Respond/Block）

• EDR/XDR⇄NDR⇄NGFWを連携し、自動隔離/IOC封止をプレイブック化（初動5分以内に端点隔離）。CISA

• サービスアカウント異常・ハニートークンで“正当アカウント悪用”を検知。

• 3-2-1-1-0バックアップ（オフライン/Immutable含む）＋四半期ごとの復旧演習。NISTのランサムウェアRMで“計画の定期テスト”を要求。NIST Publications

運用KPI（最短で追う数値）

• 外部公開RDP=0、未管理端末=0、重大パッチ7日内適用率≥95%、EDRカバレッジ≥98%。

• 復旧RTO：1週間以内を目標（2025年調査で“1週間以内復旧”が半数超）。Cyber Security Asean

参考（記事の数値と最新アップデート）

• CISA #StopRansomware Guide（最新版, 2025/03）：SMB監視、MFA、IDS/EDR運用、ログ保持など詳細手順。CISA

• NISTIR 8374（Ransomware Risk Management）：**「バックアップを守り、復元テストを定期実施」**を明記。NIST Publications

• NIST 800-63B（AAL2/パスキー関連）＋国内技術解説：条件を満たすパスキーはAAL2相当での運用が可能。pages.nist.govnri-secure.co.jp

• RMM悪用の注意喚起（CISA/NSA/MS-ISAC）：正規RMMの悪用事例と対策。CISAU.S. Department of War

• Sophos State of Ransomware 2025：平均復旧コスト$1.53M、身代金支払い49%、53%が1週間以内で復旧。2024版の$2.73Mから改善。SOPHOSAxios

• FAQ（実装のつまずきどころ）

  • Q. RDPゼロが難しい部門があります。最小の妥協案は？
    A. 例外機はVPN後段＋パスキーMFA＋時間/発信元制限＋録画付きジャンプサーバ。月次で例外棚卸し。CISA

  • Q. 東西監視はどこから？
    A. AD/PowerShellの拡張ログ＋SMB/DNSの可視化から着手→次にNDRセンサーをDC/仮想基盤の要所へ。CISA

  • Q. 復旧演習の頻度は？
    A. 四半期で“完全復元”をリハーサル（代表システムでRTO測定）。NISTは復元テストを推奨。NIST Publications

  用語ミニ解説

  • AAL2：NISTの認証保証レベル。条件を満たすパスキーなどで達成可。pages.nist.govnri-secure.co.jp

  • NDR：ネットワークの東西/南北トラフィックを行動分析し検知・対応する仕組み。IBM

  • 3-2-1-1-0：3コピー/2メディア/1オフサイト/1オフライン(またはイミュータブル)/0エラーでの復元確認。Veeam Software

スフィアトレーシングとはどういう意味でしょうか？

 スフィアトレーシング（Sphere Tracing）とは、**距離関数（Signed Distance Function = SDF）**を使ったレイマーチングの一種です。

概念

• 通常のレイマーチングは、レイ（視線）を一定の長さずつ進めて、どこかで表面に当たるかどうか調べます。

• スフィアトレーシングでは、**「今いる点から表面までの最短距離」**をSDFで計算し、その距離ぶんだけ一気に進めます。

• つまり、「絶対に衝突しない最大の球（スフィア）」の半径分だけ進むので「Sphere Tracing（球をたどる）」と呼ばれます。

特徴

• 無駄な判定が減り、早く表面にたどり着く。

• 複雑なオブジェクトや滑らかな曲面もリアルタイムで表現しやすい。

• SDFが正しく設計されていれば、表面を突き抜けない（オーバーシュートしない）。

まとめ

スフィアトレーシングとは、SDFの値を使って「絶対にぶつからない最大の距離」を一気に進むことで、効率よく表面との交差を検出するレイマーチングの手法です。

---

補足：

• スフィア＝球体ですが、「球を描く」のではなく「進んでも絶対ぶつからない球を想定して進む」イメージです。

• Shadertoy の多くのレイマーチ系シェーダーはこのアルゴリズムを使っています。

もっと数式や実装例を知りたい場合もお答えできます！

ShaderToy における雨エフェクト重ね合わせ

 

ShaderToy上では、背景画像に雨粒エフェクトを加えるシェーダの実例があります。例えば Élie Michel 氏の「Rain drops on screen」というShaderToyデモが有名ですgodotshaders.com。このシェーダでは iChannel0 に入力した画像テクスチャ（背景）を使用し、雨滴が落ちる効果をオーバーレイしています。雨滴部分では背景テクスチャ座標をオフセットして屈折を表現しており、雨粒の位置ではぼやけた背景が上下逆に映るようなリアルな表現になりますgodotshaders.comgodotshaders.com。ShaderToyのページ上でフラグメントシェーダのGLSLコードも公開されており、実際に動作するデモをブラウザ上で確認できます（Creative Commons BY-NC-SAライセンス）godotshaders.com。なお、同様の雨エフェクトとして BigWings 氏の「Heartfelt」github.comといった高度なShaderToy作品も存在します（こちらはテクスチャを使わず完全にプロシージャルに背景と雨を生成する例ですが、コードは公開されています）。

The Book of Shaders Editor における雨エフェクト例

The Book of Shaders Editor（GLSLエディタ環境）でも、画像上に雨を重ねるシェーダを動作させることが可能です。公式に雨専用のサンプルが提供されているわけではありませんが、既存のGLSLコードをコピーして実行できます。例えば、前述のShaderToy用シェーダを少し修正し、u_tex0 として背景画像のサンプラーを定義すれば、同様の効果を得られます。また参考になるコードとして、Gene Kogan氏のProcessing向けシェーダ例集に含まれる「rain.glsl」がありますgithub.com（Processing用ですがGLSLフラグメントシェーダのコードが掲載されており、背景映像に雨のゆがみを与えるフィルタになっています）。このようなコードをBook of Shaders Editorに導入し、uniform sampler2Dで画像を読み込んでUV座標を歪ませることで、背景画像上に雨滴が垂れるエフェクトを表示できます。GLSLコード自体は公開されているため、エディタ上で編集・実行しながら確認できます。

Three.js を用いた雨エフェクト重ね合わせ

Three.js環境でも、シェーダーマテリアルを使って画像に雨エフェクトを重ねることが可能です。その実例の一つが NordicBeaver 氏によるデモ「rain-shader」ですdev.to。このデモでは、Three.jsで平面にテクスチャ（背景画像）を貼り、その上にGLSLフラグメントシェーダで雨滴によるUV歪みを加えています。雨粒は一定間隔でランダムに生成され、各雨粒の位置で背景テクスチャのUV座標をずらすことで、水滴を通したような背景像のゆがみを表現していますdev.todev.to。ライブデモが公開されており（リンク先で実際に雨滴が垂れるアニメーションを確認できます）、GitHub上で**GLSLコード（fragment shader）**も閲覧可能ですdev.todev.to。コード中には詳しいコメントも付されており、Three.jsでの実装方法（u_textureに背景画像、u_timeで時間経過を渡し、gl_FragColor計算時にUVを雨滴分だけオフセットしてtexture2Dサンプリングする処理など）が示されています。

p5.js（WEBGLモード）での雨エフェクト重ね合わせ

p5.js のWEBGLモードでも、画像や映像に雨のシェーダ効果を重ねた作品例があります。例えば、p5.js公式エディタ上の**「Rainy window」というスケッチ（作者: knagai, 2019年）では、背景となる映像の上に窓ガラスを伝う雨滴の表現を加えていますeditor.p5js.orghimco.jp。この作品ではビデオを背景テクスチャとしてキャンバスに描画しつつ、WEBGLシェーダで水滴による歪み効果と画面の曇りを実装しており、雨の日に窓越しに外を見るような演出がなされています（作品内ではビデオ音量の調整等も行われていますhimco.jp）。また、chooblarin氏による「Camera Rainy Window Effect」editor.p5js.orgというスケッチでは、カメラ映像を背景にリアルタイムで雨粒エフェクトを重ねています。こちらはユーザーのカメラ入力映像に対し、水滴が垂れる表現とそれによる背景像の逆転・拡大（屈折）をシェーダで実現したデモです。いずれの例でもGLSLフラグメントシェーダのコードは公開されており、p5.jsエディタやOpenProcessing上で実行可能です。コード中でshader()を用いてWEBGLモードのシェーダを適用し、uniformにテクスチャや時間を渡して雨のアニメーション**を描画しています。これらのデモページを実際に開いてみることで、静止画・動画と雨エフェクトの組み合わせを確認でき、GLSLコードも参照できます。

参考資料: ShaderToyの雨エフェクトgodotshaders.comgodotshaders.com、Codrops雨滴シェーダの概要webgl.souhonzan.org、Three.js雨シェーダのコード抜粋dev.to、p5.js雨窓効果スケッチ一覧editor.p5js.orgなど。

https://geni.us/o5KO1Qg