YAPC(ヤップシー/ヤプシー)とは、Yet Another Perl Conference の略称である。 世界規模で行われており、アジア版はYAPC::Asiaと呼ばれる。YAPC::Asiaの運営は2009年からJPA(Japan Perl Assosiation)が行っている。 日本では
が開催された。
参加しました。会社のパーカーを着て会場をふらふら歩いていたり*1、コーヒーを飲んでいたりしたと思います。 yapcjapan.org 印象的だったトーク・セッション なぜインフラコードのモジュール化は難しいのか - アプリケーションコードとの本質的な違いから考える speakerdeck.com アプリケーションコードにおいては実装の詳細を隠蔽して処理を記述することが抽象化の目的であるのに対して、インフラコード (IaC) においては実装の詳細 (インフラ構成) を再利用可能にすることが目的であり、異なる目的に対して同じような考え方で抽象化を行うとうまくいかない、ということがうまく分析・言語化…
先ほど、夜の便で無事に羽田に帰ってきた。まずは、素晴らしいカンファレンスを作ってくれたスタッフの方にお礼を言いたい。 最近持ち歩く PC が GPD win min なので、メモは取らなくていいかなあと思っていたのだけど、やっぱりメモをとったほうが頭に入ってくるので、結局全編メモを取りながら聞いていた。 hiratara.hatenadiary.jp hiratara.hatenadiary.jp 聞いた中で面白かったのは、まず macopy さんのトーク で、コーディングエージェントがどう動いているのか短時間でよくまとまっていて素晴らしかった。 yoshiori さんのトーク も業務で技術的…
R7春 午後Ⅰ 問1「サプライチェーンリスク対策」—問題文のていねい解説 1) 物語の設定(登場人物とシステム) L社は外部ベンダーやオフショア拠点も関わる開発・運用体制を持ち、設計書は「プラットフォームG」に保存、静的解析ツール「F」は開発端末とプラットフォームGに導入されています(Fは“ビルドが通ったソースに対してのみ”正常検査可。CI/CD管理機能で自動化も可能) 。経営陣の指示で、情報セキュリティ担当Bさんは登録セキスペのD氏と一緒に、サプライチェーンリスク対策を強化した社内ガイドラインを作る流れです 。 2) ガイドラインの骨子(表1) ガイドラインは「共通・調達・開発・リリース/デ…
R元秋2-2「工場セキュリティ」問題文の要点と流れ(丁寧解説) 1) 物語の舞台(A社/A‑NET/規程) A社は本社+3工場を持つ製造業。事業所内外をつなぐ基幹ネットワーク「A‑NET」をシステム部が管理しており、社内機器の多くが接続されています。各工場は独立部門として扱われます。 全社共通のセキュリティ規程があり、各部門はこれに従って機器を管理します(図1・図2が参照図)。 図1の注記では「工場間の直接通信はFWで禁止」「各工場に従業員が使えるファイルサーバがある」と明記。 規程の骨子:標準PCはシステム部管理、パッチ適用とマルウェア対策は必須/業務用ソフトの導入は事前許可/A‑NETの管…
問題文の詳説(R元・秋 午後Ⅱ 問1) この問題は、WebアプリをDevOps体制で継続開発・運用している企業において、構成管理の甘さを突かれてマルウェア感染が起きた事例を素材に、インシデントの読み解き・原因特定・妥当な対策・開発運用プロセスの改善までを一連で考えさせる構成です。実務的な観点(脆弱なポート開放、FWルール、権限、ログ、検証環境、変更管理、コンテナ活用)を横断して問うのが狙いです。また、公式の出題趣旨は「DevOpsを実践する企業におけるセキュリティインシデント対応と対策力」を測ることにあります。営業要件だけでなく、DevOps特有のリスク認知と対処まで含めて能力を見る、と明言さ…
以下は、令和元年度 秋期 SC 午後Ⅰ「問2」設問2(対策の検討)の狙い→考え方→根拠→最終答案の順での詳解です。最後に字面そのままの公式解も添えます。 (1) 署名検証に使う証明書は? 狙い「正規“実行ファイル”かどうか」を署名で見極めるなら、どの証明書かを問う基礎。図4の方針は「ディジタル署名が付与されていない実行ファイルからの通信をEDRで遮断」→「④署名を検証すれば正規実行ファイルか否かを判定できる」でした。 考え方 実行ファイルに使うのはコードサイニング証明書。 S/MIME=メール、TLSサーバ/クライアント=通信路の認証でありバイナリ自体の署名用途ではない。 答案:エ(コードサイ…
全体像(舞台設定) N社(従業員500名)のメール基盤が題材。DMZに「外部DNSサーバ」「外部メールサーバ」、社内に「内部DNS」「内部メールサーバ」がある一般的構成です。社外とのメールは外部メールサーバが受け持ち、公開DNSは n-sha.co.jp のMXとそのAレコード(mail.n-sha.co.jp → x1.y1.z1.1)を正しく引かせるよう設定済みです。ここまでが“現状のメール到達の仕組み”を描いています。 送信者アドレスの2種類(用語の整理) メールの“送信者アドレス”には2系統あります。 Envelope-FROM:SMTPのMAIL FROMで宣言され、バウンス(不達通…
以下は、令和元年度 秋期 SC 午後Ⅰ「問3 標的型攻撃への対応」の問題文を、流れと狙いがつかめるように噛み砕いて整理した解説です。まず“どんな状況で何を導入し、どう対応したか”の全体像を押さえると読みやすくなります。 全体像(どんな話?) J社の素性:ビッグデータ解析の調査会社(従業員150名)。Webアクセスや社外メールのやり取りでインターネットを常用。情報セキュリティポリシは整備済み。 事件の発端:3月に標的型攻撃でPCがマルウェア感染、業務サーバの秘密情報が外部に送信。感染“疑い”含め40台を初期化、復旧まで48時間で業務停止に。被害後、コンサルの助言で予防だけでなく“感染後の拡大防止…
物語の流れ(読み取りの道筋) G社の環境従業員1,500名の製造業。Webとメールを日常利用。情報セキュリティポリシを整備済み。以後の図表(図1・表1・図2)に社内ネット構成、機器・ソフト、既存のパッチ配信手順が載ります。 図1の要点:DMZだけがインターネット通信可/FWはステートフルで許可・拒否とログ送信/全PCにEDRエージェント、一般従業員に管理者権限なし。これが後段の**“どこでパケットをとるか/どう隔離するか”**の根拠になります。 図2:現行のパッチ配信プロセス(1) ベンダがパッチ公開→担当者がリリースノート確認(2) 検証LANのPCに適用し、アプリを2日間動かして a を確…
全体像(舞台設定) A社は中規模(従業員500名)。ネットワークは図1・表1で示され、社外に公開Web、社内に業務・内部Web・内部DNS、DMZに公開系を配置。外部DNSサーバは「権威DNS」兼「フルサービスリゾルバ(再帰解決)」として使われています(ここが重要な伏線)。 ブラウザの名前解決はプロキシが外部DNSへ投げる設定。加えて、プロキシとメールサーバが“フルリゾルバ”としても動作します。DNSソフトはOSSの“Dソフト”。 FWルール(表2)では、外部DNSサーバ⇄インターネットのDNSが双方向で許可(項番5・6)。最後はデフォルト拒否。 まず「リスク整理」と「基本設計変更」の筋 ニュ…