top of page
T4c. Products
T4c. Products は、「自分自身が使い続けたくなる、ミニマルでわかりやすいUX」を大切にしたモバイルアプリ開発と、技術情報の発信を行う個人プロジェクトです。
日常の中にある小さな課題を、シンプルで使いやすいアプリとして形にしながら、IT、ソフトウェア開発、セキュリティに関する関心事や検証内容をブログとして発信しています。
運営者プロフィール
上場企業にて10年以上、組み込みソフトウェア開発に携わり、現在はセキュリティエンジニアとして活動しています。
米国におけるサイバーセキュリティの専門資格であるCISSP、CSSLP、GSEC、GCIHを保有し、ソフトウェア開発とサイバーセキュリティの両面から、実践的な知識の発信に取り組んでいます。
T4c. products では、ガジェット、モバイルアプリ、セキュリティ技術を中心に、日々の検証や開発で得た知見をブログとして投稿しています。
最新投稿
病院のサイバー被害は、もう“情報漏えい”だけでは語れない
Hi, there. 今回は、医療機関に対するサイバー攻撃について私見を述べます。 「情報漏洩」だけの対処では、もう足りない 病院へのサイバー攻撃というと、多くの人はまず「個人情報が漏れたか」を思い浮かべます。たしかにそれは重大な問題です。しかしながら、今の医療現場で本当に深刻なのはそれだけではありません。 最近の病院被害では、「電子カルテが見られない」、「予約や検査が止まる」、「救急の受け入れが制限される」、「手術が延期される」、といった医療機関の機能そのものに対する影響が広がっています。つまり、サイバー被害は「情報の問題」だけではなく、「医療が止まる問題」になっているのです。医療分野の災害対応や継続計画を扱う米国HHSのASPR TRACIEも、近年の医療機関へのサイバー攻撃は患者ケアと業務継続のあらゆる側面に大きな影響を与えていると整理しています。 「Recent cyberattacks on healthcare facilities have had significant effects on every aspect of pat
9月6日
CVE-2026-63077：TeamCityの復旧をCI制御プレーンの信頼再構築として進める
CVE-2026-63077は、TeamCity On-Premisesのagent polling protocolに関わる未認証RCEです。更新だけで完結させず、エージェント、資格情報、ビルド設定、成果物の信頼をどう再評価するかを整理します。
8月16日
Ubuntu VMで学ぶ「属性ベースアクセス制御：ABAC」
“ユーザーやロールだけで決めない”アクセス制御を、polkitで手を動かして理解する アクセス制御の説明では、RBAC まで来ると話がだいぶ整理しやすくなります。「運用担当だからこの操作を許可する」「監査担当だから閲覧だけ許可する」といった形で、役割ごとに権限をまとめられるからです。 ただ、実務ではそれだけで収まらない場面が増えています。同じ管理者でも、社内ネットワークからの操作と私物端末からの操作では扱いを変えたい。同じ医師でも、自分の担当患者に対する閲覧と、他科の患者記録へのアクセスを同じにしたくない。こういう条件が入ってくると、ロールだけで押し切る設計はすぐに苦しくなります。 ここで出てくるのが ABAC です。ABAC は Attribute-Based Access Control、属性ベースアクセス制御です。RBAC が「役割」でアクセスを決めるモデルだとすれば、ABAC はもう一段細かく考えます。アクセスの可否を、利用者の属性、資源の属性、操作の種類、時間帯、場所、端末状態など、複数の条件で判断する考え方です。Ubuntu で標準
8月2日
Ubuntu VMで学ぶ「ロールベースアクセス制御：RBAC」
sudoersで“人に権限を配る”運用から卒業す る Linux サーバー運用でありがちなのが、必要になるたびに sudo 権限を人へ足していくやり方です。最初は早いのですが、人数が増え、作業内容が増え、監査が入るころにはだいたい破綻します。 誰が何をできるのかが見えにくい。不要な権限が残る。退職や異動のたびに見直し漏れが出る。このあたりは、現場でよくある事故です。この問題に対して効く考え方が、**ロールベースアクセス制御（RBAC）**です。個人ごとに権限をばらまくのではなく、 役割ごとに権限を束ねて与える 。Ubuntu の日常運用では、その入り口として sudoers が非常に使いやすいです。 この記事では、Ubuntu VM 上で sudoers を使って、RBAC 的な運用へどう寄せていくかを具体的に見ていきます。 RBAC は“人”ではなく“役割”に権限を持たせる RBAC の考え方自体は単純です。 たとえば、次のように分けます。 監査担当: ログ閲覧だけ 運用担当: サービス再起動と状態確認だけ バックアップ担当: バックアップコマ
7月19日
Ubuntu VMで学ぶ「強制アクセス制御：MAC」
AppArmorで「そのユーザーなら読める」を「そのプロセスには読ませない」に変える Linux の権限管理に少し慣れてくると、こんな場面にぶつかります。 「ファイル権限としては読めてしまう。だが、そのアプリケーションには読ませたくない。」 この時点で、chmod や ACL だけでは少し苦しくなります。なぜなら、それらは基本的に「ユーザーやグループに対する権限設定」だからです。一方、実際に縛りたい対象はユーザーそのものではなく、 その権限で動くプロセス であることが多いからです。 ここで必要になるのが強制アクセス制御（MAC: Mandatory Access Control）です。Ubuntu では、この MAC を担う代表的な仕組みが AppArmor です。 この記事では、Ubuntu VM を使って AppArmor を触りながら、DAC では足りない部分をどう補うのかを具体的に見ていきます。 AppArmor は“プログラム単位の制限” AppArmor の見方は難しくありません。一言で言えば、 実行ファイルごとに許可された操作を定
7月5日
Ubuntu VMで学ぶ「任意アクセス制御：DAC」
chmodだけで終わらせない、DACとACLの実践的な使い分け Linux を触っていると、最初に覚えるアクセス制御はたいてい chmod と chown です。実際、それだけでもかなり多くのことはできます。ですが、少し運用らしいことを始めると、すぐに足りなくなります。 たとえば、あるディレクトリは基本的に開発者グループだけが触れるようにしたい。ただし監査担当の1人だけは読み取りだけ許可したい。こうした要件は珍しくありません。むしろ日常的です。 この種の制御を理解するうえで、最初に押さえるべきなのが任意アクセス制御（DAC: Discretionary Access Control）です。Linux の通常の所有者・グループ・その他の権限は、まさにこの DAC にあたります。さらに POSIX ACL も、この DAC を実務向けに拡張した仕組みです。 この記事では、Ubuntu VM 上で DAC を実際に触りながら、chmod の基本だけでなく、 ACL を含めてどう使い分けるか まで見ていきます。 まずは検証用ユーザーを作る...
6月21日
bottom of page