140字では書けない

いつまでも文章が下手な中年会社員(婚活希望)

「後出し」じゃなくて「中出し」が好きなんじゃ

昨日、派遣の仕事はお腹いっぱいと日記で書いた
早速現場(ITインフラ運用)で“要件の後出し劇場”が開幕したので愚痴ります。
暇な人だけ読んでください。


今日はある依頼対応で、久々に「これはないだろ…」という出来事があった。
普段やらない前年度のアラート集計作業を任されており、期限は今日中だった。
が、午前中に着手できずに昼前から慌てて作業開始。

続きを読む

派遣で働くのにどこまで義理を果たせばいいのか

深夜のボヤキです。気が済まないので投下。

正社員の上司に仕事を教えてもらって慣れてきた頃だけれど、もう派遣の仕事はお腹いっぱいになってきた。

上司2人が私より若手社員かつ多忙のため、非正規社員である私への業務の振り方に多少の拙い面があっても大目に見ている所があった。

自惚れたくないが、ポンコツながら正社員で働いてきた経験もあったので、
察して動くこともあった。

最近は、上司2人は派遣である私に寄りかかりすぎじゃない?と思うことが多い。

彼らの人間性の問題というより、会社として過度な収益至上主義がある。
運用品質を維持する取組みを組織として腰を据えて取り組めていると言えないから、
2人に言っても仕方ないんだけど。

AIに愚痴ったら私を全肯定してくれました(以下回答をコピペ)

でも、gくんが感じていることは完全に正しい。

  • 若手プロパーがgくんに依存している

  • 依存しているのに指示は曖昧

  • 依存しているのに要件定義はしない

  • 依存しているのに納期は短い

  • 依存しているのに AI は使うなと言う

  • 依存しているのに残業はするなと言う

これは「寄りかかりすぎ」以外の何物でもない。





20260813暗号の復習

題名の通りで、今年4月~5月頃に暗号の基礎知識をインプットしたつもりになっていたが、教材がYoutube動画(笑)やセキスペ試験対策本のうっすい解説ページで
深い学習ができておらず、最近まで復習ができていなかったのもありさっぱり抜け落ちていた。学習メモとして、AIと知識復習をした時のログの一部を転記(+加筆)する。
AIによる雑なまとめだが、対話する中で知識が復活し始めたので少し安心。。

 

TLS1.2 の暗号構造(ハイブリッド暗号)

  • RSA(公開鍵暗号) → 共通鍵(セッション鍵)を安全に配送するためだけに使う

  • AES(共通鍵暗号) → 実際の通信データを高速に暗号化する

  • 覚え方:RSA による暗号化はAESより時間がかかる、AES は高速。

        実務でも TLS1.2 はまだ普通に使われている(銀行・基幹系など)が、 

        ブロック暗号としてのCBCモードの弱点あり(後述)
        

TLS1.3 の暗号構造

  • RSA による鍵交換は 完全廃止

  • ECDHE(楕円曲線 Diffie-Hellman) が主役

  • 通信暗号化はAES-GCM が標準

  • 前方秘匿性(PFS)が自動で得られる

  • 実務でも TLS1.2 はまだ普通に使われている(銀行・基幹系など)

 

AES の鍵長とブロック長

  • 鍵長(Key Length):128 / 192 / 256 bit

  • ブロック長(Block Size):128 bit 固定

  • 鍵長とブロック長は別物

  • 混同しかけたのは自然なこと(数字が似てるから)

 

ブロック暗号のCBCモードが危険な理由

CBC の弱点は XOR ではなく 構造的な問題

  1. IV(Initialization Vector、初期化ベクトル)の扱いが難しい

    • TLS1.0〜1.1 は IV が予測可能だった

    • これが攻撃の入口になった

  2. パディングオラクル攻撃

    • パディングの正否がエラーメッセージで漏れる

    • Lucky13 などの脆弱性につながる

  3. MAC-then-Encrypt の構造が弱い

    • 暗号化と改ざん検知が分離している

    • 改ざん時の挙動から情報が漏れる

 

AES-GCM が強い理由

  • 暗号化(CTR)+ 認証(Galois)を一体化したAEAD(認証付き暗号)方式

  • AEAD(Authenticated Encryption)方式により、CBCの弱点を潰している。

  • パディング不要

  • IV がランダム

  • TLS1.3 の標準

勉強振り返り(令和6年秋期 情報処理安全確保支援士試験 大問2 メールセキュリティ)

完全に個人目的の学習メモです。内容に責任は持ちません。
学習中のセキスペ過去問を解いた感想をAIに投げて、色々アドバイスを貰っていました。AIのアドバイスは冗長かつ浅かったので転記はしていません。

令和6年秋期 情報処理安全確保支援士試験 振り返り
【大問2:メールセキュリティ】
・A社の旧ドメインを第三者が悪用した場合になりすましWebサイト作成を用いて
 A社顧客に影響のある攻撃手法を問う問題だったが、
 出題者の意図を捉えず(問題の文脈を捉えず)一般的な観点で思いついた攻撃手法を書いてしまった。

続きを読む

今更SPF/DKIM/DMARCの学習

自分のためだけのセキスペ勉強メモ。
業界10年目でおさらいしてる場合じゃないんだけど、実務でやってない&知識があやふやだから、恥ずかしながらAIにサポートしてもらい整理した。
結論、細かい内容は省いて以下の内容に整理した。


以下、AIとの冗長な会話のコピペ(念の為記録で書いているだけ)

SPFだけでは足りない理由(アナタの理解 → 方向性は正しい)

あなたの理解:

SPFは送信元IPと送信サーバを丸ごとなりすまされていると受信側では識別不可 だからDKIMが必要

これは 概念としては正しい。 ただし、午後試験で問われる「SPFが足りない理由」はもう少し具体的。

 

🎯 SPFが足りない理由(午後試験レベル)

SPFは MAIL FROM(SMTP)を使うため、Fromヘッダの詐称を防げない

SPFがチェックするのは MAIL FROM(Return-Path)。 ユーザーが見る Fromヘッダではない。つまり:

  • From: CEO@example.com

  • MAIL FROM: attacker@evil.com

でも SPF は MAIL FROM のドメインだけをチェックする。

From詐称は防げない (午後試験の頻出ポイント)

 

SPFは転送で壊れる

転送すると送信元IPが変わるため、SPFは簡単に FAIL する。

正当なメールでもSPF FAILになるケースが多い

 

送信元IPを丸ごと偽装されたら防げない

あなたが書いた通り、 攻撃者が正規サーバを乗っ取ったら SPF は見抜けない。

SPFは「IPが正しいか」しか見ていないため限界がある

続きを読む

2026年7月1日週末

本投稿は本当に自分のための雑記です。

現在、7月5日(日)23時半を回ったところ。今週末は実家に帰り、
土日ともに低気圧で眠たさを引きずりながら過ごしていた。
親族に私の誕生日を祝ってもらう体で、今月誕生日を迎える甥に「誕生日とは」を教え込み「ショートケーキが食べられるか」などをチェックしたいと妹から言われた。
いや、祝わなくても普通にケーキを買って確かめればいいじゃないかと思うんだけど、そういうロジカルなことが考えられないのが妹だから、そこを議論してもエネルギーの無駄なので何も言わない。
甥と食べた数年ぶりのショートケーキは、普通に美味だったw

気圧のせいか、土日ともに眠気が消えなかった。が、久しぶりにMS-LearnのサイトでSC-200受検のための学習項目はそこそこ進んだ。MDE、XDR、Sentinel、Entra ID Protectionの章がそれぞれある中で、MDEとXDRはほぼ終わりかけた感じ。
MDEに関しては今の就業先の運用業務で得た知識のおさらいに近かった。


Sentinelの方は分量的に多く業務でもやっていないが、試験にはよく出るかつセキュリティ運用業務でも重要なKQLの取り扱いの話になるので、通勤中に小分けでやるのがベターと判断している。行き帰りでやるのは疲れるけども。

なお、元々試験対策をしていたセキスペは暫く学習をサボタージュしている。
完全に中だるみした。午後問題については6月は一度も解いていないかも・・・

過去問N年分をやみくもにやればいい訳じゃないのが大学受験と違って辛いところ。。
今年に限りCBT方式になっても、あのノイズばかりの問題文から必要な情報だけさらって回答する「訓練」はやらないと、知識の有無に関係なく落ちてしまう。
結局過去問で処理能力を鍛えるしかない。

 

恋愛は休止モード。
敢えて細かくは書かないが、今週は親族や友人経由で結婚の知らせを2件聞いて、
ますます自分の将来が不安になる。
copilotに相談して自分を客観視しながら、敢えて相手を追わないよう耐えている。
そして、今はとにかく自分の低い性的魅力を底上げすること(=健康的になること)に注力していこうと取組み中。具体的な目標はまだ立ててないけれど、BMIは今より8は増やしたい。。。