Hi, there. 今回は、医療機関に対するサイバー攻撃について私見を述べます。 「情報漏洩」だけの対処では、もう足りない 病院へのサイバー攻撃というと、多くの人はまず「個人情報が漏れたか」を思い浮かべます。たしかにそれは重大な問題です。しかしながら、今の医療現場で本当に深刻なのはそれだけではありません。 最近の病院被害では、「電子カルテが見られない」、「予約や検査が止まる」、「救急の受け入れが制限される」、「手術が延期される」、といった医療機関の機能そのものに対する影響が広がっています。つまり、サイバー被害は「情報の問題」だけではなく、「医療が止まる問題」になっているのです。医療分野の災害対応や継続計画を扱う米国HHSのASPR TRACIEも、近年の医療機関へのサイバー攻撃は患者ケアと業務継続のあらゆる側面に大きな影響を与えていると整理しています。 「Recent cyberattacks on healthcare facilities have had significant effects on every aspect of pat

CVE-2026-63077は、TeamCity On-Premisesのagent polling protocolに関わる未認証RCEです。更新だけで完結させず、エージェント、資格情報、ビルド設定、成果物の信頼をどう再評価するかを整理します。

“ユーザーやロールだけで決めない”アクセス制御を、polkitで手を動かして理解する アクセス制御の説明では、RBAC まで来ると話がだいぶ整理しやすくなります。「運用担当だからこの操作を許可する」「監査担当だから閲覧だけ許可する」といった形で、役割ごとに権限をまとめられるからです。 ただ、実務ではそれだけで収まらない場面が増えています。同じ管理者でも、社内ネットワークからの操作と私物端末からの操作では扱いを変えたい。同じ医師でも、自分の担当患者に対する閲覧と、他科の患者記録へのアクセスを同じにしたくない。こういう条件が入ってくると、ロールだけで押し切る設計はすぐに苦しくなります。 ここで出てくるのが ABAC です。ABAC は Attribute-Based Access Control、属性ベースアクセス制御です。RBAC が「役割」でアクセスを決めるモデルだとすれば、ABAC はもう一段細かく考えます。アクセスの可否を、利用者の属性、資源の属性、操作の種類、時間帯、場所、端末状態など、複数の条件で判断する考え方です。Ubuntu で標準

sudoersで“人に権限を配る”運用から卒業す る Linux サーバー運用でありがちなのが、必要になるたびに sudo 権限を人へ足していくやり方です。最初は早いのですが、人数が増え、作業内容が増え、監査が入るころにはだいたい破綻します。 誰が何をできるのかが見えにくい。不要な権限が残る。退職や異動のたびに見直し漏れが出る。このあたりは、現場でよくある事故です。この問題に対して効く考え方が、**ロールベースアクセス制御（RBAC）**です。個人ごとに権限をばらまくのではなく、 役割ごとに権限を束ねて与える 。Ubuntu の日常運用では、その入り口として sudoers が非常に使いやすいです。 この記事では、Ubuntu VM 上で sudoers を使って、RBAC 的な運用へどう寄せていくかを具体的に見ていきます。 RBAC は“人”ではなく“役割”に権限を持たせる RBAC の考え方自体は単純です。 たとえば、次のように分けます。 監査担当: ログ閲覧だけ 運用担当: サービス再起動と状態確認だけ バックアップ担当: バックアップコマ

AppArmorで「そのユーザーなら読める」を「そのプロセスには読ませない」に変える Linux の権限管理に少し慣れてくると、こんな場面にぶつかります。 「ファイル権限としては読めてしまう。だが、そのアプリケーションには読ませたくない。」 この時点で、chmod や ACL だけでは少し苦しくなります。なぜなら、それらは基本的に「ユーザーやグループに対する権限設定」だからです。一方、実際に縛りたい対象はユーザーそのものではなく、 その権限で動くプロセス であることが多いからです。 ここで必要になるのが強制アクセス制御（MAC: Mandatory Access Control）です。Ubuntu では、この MAC を担う代表的な仕組みが AppArmor です。 この記事では、Ubuntu VM を使って AppArmor を触りながら、DAC では足りない部分をどう補うのかを具体的に見ていきます。 AppArmor は“プログラム単位の制限” AppArmor の見方は難しくありません。一言で言えば、 実行ファイルごとに許可された操作を定

chmodだけで終わらせない、DACとACLの実践的な使い分け Linux を触っていると、最初に覚えるアクセス制御はたいてい chmod と chown です。実際、それだけでもかなり多くのことはできます。ですが、少し運用らしいことを始めると、すぐに足りなくなります。 たとえば、あるディレクトリは基本的に開発者グループだけが触れるようにしたい。ただし監査担当の1人だけは読み取りだけ許可したい。こうした要件は珍しくありません。むしろ日常的です。 この種の制御を理解するうえで、最初に押さえるべきなのが任意アクセス制御（DAC: Discretionary Access Control）です。Linux の通常の所有者・グループ・その他の権限は、まさにこの DAC にあたります。さらに POSIX ACL も、この DAC を実務向けに拡張した仕組みです。 この記事では、Ubuntu VM 上で DAC を実際に触りながら、chmod の基本だけでなく、 ACL を含めてどう使い分けるか まで見ていきます。 まずは検証用ユーザーを作る...

“もう一つの署名”が持つ意味 PQC の署名方式を考えるとき、まず中心になるのは ML-DSA です。一方で、実運用を前提にすると、それだけで整理を終えるのはやや危うい見方でもあります。政府、金融、重要インフラのように移行期間が長く、影響範囲も広い領域では、単一の数学的前提に依存しすぎない設計にも意味があります。NIST は ML-DSA に加えて SLH-DSA も標準化しており、署名のPQC移行は「どの方式を主に使うか」だけでなく、「別系統の方式をどう持つか」まで含めて考えるべき段階に入っています。 SLH-DSA の重要性は、単に“別の署名方式がある”という話ではありません。ML-DSA とは異なる基盤を持つ標準方式が用意されていること自体が、長期運用や高価値資産を扱う設計において意味を持ちます。PQC を実務として捉えるなら、SLH-DSA は予備知識ではなく、暗号アジリティを考えるうえで押さえておくべき要素です。 SLH-DSA は何をするアルゴリズムか SLH-DSA は、NIST が FIPS 205 で定めた stateless

Hyper-VでLinux系のVMを構築していると、Hyper-Vマネージャー上ではVMが「実行中」になっているのに、VMConnectの画面が黒いまま、ログイン画面が出ない、あるいはGUIの起動途中で止まったように見えることがあります。 この状態になると、VMが壊れた、インストールに失敗した、ネットワークやディスク設定を間違えた、と考えてしまいがちです。 しかし、実際にはVMそのものは正常に起動していて、GUIの表示やログインマネージャだけがうまく出ていないという場合があります。 そのときに試したいのが、仮想コンソールの切り替えです。 VMConnect画面でCtrl + Alt + F2 / F3 / F4を試す VMConnectの画面を開いた状態で、以下のキーを押します。 Ctrl + Alt + F2 これで反応がなければ、続けて以下も試します。 Ctrl + Alt + F3 Ctrl + Alt + F4 Linuxでは、GUIの画面とは別に、CUIでログインできる仮想コンソールが用意されていることがあります。 そのため、GUI側の

公開情報から見る攻撃タイムラインと、防御側が気をつけるべきポイント ランサムウェア被害は、利用者の画面に身代金要求が表示された瞬間に始まるわけではありません。多くの場合、その前に「侵入口の確保」「認証情報の悪用」「内部探索」「権限拡大」「バックアップ破壊」「情報窃取」といった準備段階があります。 公開レポートを見ると、攻撃は以前より速くなっています。Sophosの2025年調査では、インシデントレスポンス案件におけるランサムウェアの中央値滞在時間は4日、Mandiantの2025年レポートでもランサムウェア関連侵害の中央値滞在時間は6日で、半数以上が1週間以内に検知されています。つまり、防御側には「数週間かけて調査する余裕」はなく、初期侵入後の数日が勝負になります。(SOPHOS) 1. 初期侵入：入口はメールだけではない 従来は「ランサムウェア＝怪しい添付ファイル」という印象が強くありました。しかし、現在の侵入口はもっと広いです。 MITRE ATT&CKでは、初期アクセスは「攻撃者がネットワーク内に足場を得る段階」と定義され、スピアフィッシン

育児の中でも、授乳や搾乳の記録は想像以上に細かく、そして毎日続いていくものです。「いつ搾乳したか」「どれくらい飲んだか」「どの子にどれだけあげたか」「保存量は足りているか」――こうした情報は、その場では覚えていられるつもりでも、睡眠不足の中ではすぐに曖昧になってしまいます。 そこで開発したのが Mom Milk です。 Mom Milk は、母乳・搾乳・哺乳の記 録を、見やすく・続けやすく管理するためのアプリです。日々の記録だけでなく、グラフによる可視化、赤ちゃんごとの摂取量管理、保存量の把握までをひとつのアプリにまとめています。 双子やきょうだい育児のように、記録対象が複数人になる場面でも使いやすいように設計しているのが特徴です。 Mom Milkでできること Mom Milk の主な役割は、授乳まわりの記録を一か所に集約することです。 アプリ内では、主に次のような情報を扱えます。 搾乳量の記録 哺乳量の記録 母乳量・哺乳量の推移の確認 赤ちゃん別の摂取量の把握 保存量と消費量をもとにした残量予測 搾乳時のトラブルやメモの記録...

資格を取りたい。毎朝歩きたい。勉強を続けたい。仕事で成果を出したい。健康、人間関係、資産づくりも少しずつ整えたい。 そう思って目標を立てても、日常の中ではいつの間にか優先度が下がってしまうことがあります。大きな目標ほど、今日の一歩が見えにくい。逆に、今日の一歩が見えないと、続ける意味も感じにくくなります。 そこで開発したのが Delightful Life です。 Delightful Life は、人生の目標や習慣をRPGのよう に育てていく目標管理アプリです。健康、学習、仕事、人間関係、資産といったライフスタッツを成長させながら、日々の行動を経験値として積み上げていきます。 人生の進捗を「レベル」として可視化する Delightful Life の中心にあるのは、レベルと経験値です。 目標を達成したり、習慣を継続したりすると、経験値が積み上がっていきます。その経験値によってユーザーレベルが上がり、現在のジョブやステータスの成長が反映されます。 画面上では、現在のレベル、次のレベルまでの必要経験値、現在のジョブが表示されます。たとえば、レベル1

日々のトレーニングを続けていると、意外と面倒になるのが「記録」です。 筋トレの重量や回数、体重や体脂肪率、有酸素運動の距離や時間。どれも後から振り返ると重要な情報ですが、入力が複雑だったり、画面がごちゃついていたりすると、記録そのものが続かなくなります。 そこで開発したのが Workouts Note です。 Workouts Note は、筋トレ、体組成、有酸素運動、グラフ確認をひとつにまとめた、ヘルスケア／フィットネス向けの記録アプリです。目的は、細かい分析機能を詰め込みすぎることではなく、毎日の運動記録をできるだけ迷わず残せるようにすることです。 カレンダーで運動記録を俯瞰する Workouts Note では、月ごとのカレンダーから記録日を確認できます。 カレンダー上には、ワークアウト、体組成、有酸素運動の記録が色付きで表示されます。その日に何を記録したのかが一目で分かるため、「最近トレーニングが空いている」「有酸素運動の頻度が少ない」といった傾向を把握しやすくなります。 筋トレは継続が重要ですが、継続できているかどうかは、感覚だけでは意

Hi, there. 本日のトピックは、Elastic Stackです。 ― “検索エンジン”の先にある、監査と可視化の実用ライン Elastic という名前を聞くと、いまでも「Elasticsearch のこと」と受け取られることが少なくありません。たしかに Elasticsearch は Elastic の中核であり、検索と分析を担う重要なエンジンです。けれど、いま実際に手を動かして使う対象は、Elasticsearch 単体ではなく、Elasticsearch、Kibana、そして必要に応じて Elastic Agent や Fleet を含めた Elastic Stack 全体です。Elastic 公式も、Elastic Stack を「データを安全に保存し、検索し、分析し、可視化するために連携する製品群」と説明しています。 この違いは、言葉の問題ではありません。「Elasticsearch で何ができるか」と考えると、どうしても検索エンジンの延長として見てしまいます。ですが、「Elastic Stack で何ができるか」と捉え直すと、話

CA を学ぶとき、OpenSSL だけでは少し見えにくいものがあります。たとえば、管理者は誰なのか、どの利用者にどのプロファイルで証明書を出すのか、発行後の監査や権限分離をどう考えるのか、といった運用の側面です。そうした“ちゃんとした PKI”の空気を自宅 lab に持ち込みやすいのが EJBCA Community です。公式には Community コンテナを使った quick start が用意されており、Docker で短時間に試せます。 EJBCA の良さは、単に証明書を一枚作るだけで終わらないことです。CA、エンドエンティティ、管理者証明書、プロファイルといった要素が UI 上で見え、PKI を“運用する仕組み”として理解しやすい構造になっています。自宅環境でも、企業や組織で使う CA 製品の手触りをかなり具体的に確認できます。 (docs.keyfactor.com) この記事で扱う内容 今回は Ubuntu VM 上で Docker を使って EJBCA Community を起動し、以下を確認します。 Docker 環境の準備

証明書を自宅で試そうとすると、多くの人はまず OpenSSL を思い浮かべるはずです。秘密鍵を作り、CSR を作り、署名し、必要なら失効や配布を考える。PKI を学ぶ入り口としては王道ですが、運用の現場では証明書のライフサイクル全体を管理できるような仕組みが利用されています。 HashiCorpのVaultは、OpenSSLよりも何段階もステップアップした証明書管理が行えるツールの一つです。また、証明書管理の自動化を前提にした仕組みを味わえるのがVaultの特徴でもあります。誰が、どんな条件で、どんな寿命の証明書を受け取れるかをAPIとポリシーにより制御するという思想で作られています。HashiCorp 公式でも、通常の手動フローを経ずに動的な X.509 証明書を発行できる仕組みとして説明されています。 (HashiCorp Developer) 今回は、このVaultによる証明書管理サーバーを実際に構築し証明書管理の基本やVaultについて学んでいきたいと思います。 この記事で扱う内容 今回は Ubuntu VM 上に検証用の Vault サ

量子時代に、署名の信頼をどう守るか PQC が必要になる理由は、通信の暗号化だけではありません。政府、金融、重要インフラのシステムでは、「誰が作ったか」「改ざんされていないか」を確認する署名基盤も同じように量子脆弱性の影響を受けます。NIST は 2035年までに量子脆弱な公開鍵アルゴリズムを段階的に外していく方針を示しており、英国 NCSC は 2035年までの移行完了を目標にした3段階のロードマップを公表しています。EU も加盟国全体での移行開始と、重要インフラの早期移行を促しています。 そこで中核になるのが ML-DSA です。NIST は 2024年8月に FIPS 204 を承認し、ML-DSA を PQC の主要なデジタル署名標準として定めました。ML-DSA は旧称 CRYSTALS-Dilithium で、用途は 署名生成と署名検証 です。 ML-DSA は何をするアルゴリズムか ML-DSA は、秘密鍵で署名を作り、公開鍵でその署名を検証する方式です。役割自体は RSA や ECDSA、EdDSA と同じで、データの完全性と署名

組み込みソフトウェアの脆弱性管理で難しいのは、単に「CVE を検出すること」ではありません。難しいのは、その CVE がどのレイヤーに存在し、製品として本当に影響するのかを判断することです。 コンテナを使っている製品であればコンテナイメージ。Linux ベースであれば OS パッケージ。カーネルモジュールやデバイスドライバ。C/C++ で書かれたアプリケーション。さらに、Yocto や Buildroot で取り込まれる OSS、静的リンクされたライブラリ、設定ファイル、起動スクリプト、証明書、秘密情報。 これらを一つのスキャナでまとめて見ようとすると、どうしても粗くなります。逆に、レイヤーごとに「狙うべきもの」と「適した手段」を分けると、検出結果の解釈がかなり楽になります。 SBOM はこの考え方の土台になります。CISA は SBOM を、ソフトウェアコンポーネントとその関係を把握するための情報として位置づけており、脆弱性把握やサプライチェーンリスク管理に利用できます。NIST SP 800-161 Rev.1 も、製品・サービスのサプライチ

Hi, there. 今回のトピックは脅威モデリングです。 はじめに 「スマート家電や産業用ロボット、どうやってセキュリティを守ればいいの？」 そんな疑問を持ったことはありませんか？ ITシステムのセキュリティ対策（MITRE ATT&CKなど）は有名ですが、実は「組み込みシステム（Embedded Systems）」には、ハードウェア特有の守り方があります。 そこで登場したのが、2024年に公開された新しいフレームワーク『MITRE EMB3D』です。この記事では、初学者の方向けに、この便利なツールの使い方をわかりやすく解説します。 MITRE EMB3Dとは？ 簡単に言うと、「組み込みデバイスに特化した、攻撃者の狙い目と対策のリスト」です。 セキュリティエンジニアが攻撃者によるサイバー攻撃を想像する際、いわゆる脅威モデリングを実施するというのセオリーですが、STRIDEやアタックツリーなどの様々な分析手法が存在しどれを使えばいいのか選択に悩まされていました。 そんな中、単一の基板で完結するようなシステムにおける脅威モデリングの救世主となりうる

Linux ディストリビューションを選ぶとき、セキュリティだけを単体で評価するのは簡単なことではありません。カーネルや OpenSSL のバージョン、SELinux の有無だけを見ても、実運用で安全になるわけではないからです。 実際のサーバー運用では、脆弱性情報を追えること、パッチを適用し続けられること、監査に耐えられること、そして移行時に不用意なリスクを増やさないことが重要になります。 AlmaLinux は、CentOS Linux の後継候補として語られることが多いディストリビューションですが、セキュリティ観点で見ると、単に「RHEL 互換で無料」というだけではありません。本番環境で長く使う Linux として、セキュリティ運用に必要な仕組みがかなり現実的にそろっています。 ここでは、AlmaLinux の良さをセキュリティ観点で5つに絞って整理します。 1. 長期運用を前提にしたセキュリティパッチ提供 サーバーOSのセキュリティで一番重要なのは、「今安全か」ではなく「安全な状態を維持できるか」です。 AlmaLinux はエンタープライズ

Hi, there. 本日は、過去に投稿した「Splunkを使用した監査環境の構築」のWazuh版です。 Splunkの環境構築時に作成した監査対象サーバーを流用し、Splunkとの見え方の違いを見ていきたいと思います。 Wazuhには、中央コンポーネントを同一ホストにまとめた all-in-one 構成が案内されています。そのため、Splunk や Elastic と比べると最初から 監査項目の型をかなり持っており、ログを見るだけではなく、ファイル改ざん、設定不備、脆弱性まで含めて「そのホストが今どういう状態か」を見せるのが得意です。 今回の構成 今回の構成もシンプルです。 Wazuhサーバー Ubuntu Server 24.04 LTS Wazuh all-in-one 構成 名前：wazuh タイプ：Linux バージョン：Ubuntu (64-bit) メモリ：4096MB CPU：2 仮想ディスク：20GB 監査対象サーバー 前回の Splunk 編で作成した Ubuntu Server 24.04 LTS ネットワークの構成.