はじめに
こんにちは、みらい(@Minimal_Mirai)です。
さて、私は今年の9月後半から12月までピクシブ株式会社様の長期インターンに参加させて頂いておりました。
今回はその振り返りとして、こちらの個人ブログでも記録を残しておこうと思います。
また私が志望していた部署の業務内容は、比較的センシティブな情報も取り扱う関係上、一部ボカしたり記載していない内容もあります。
掲載内容については事前に承認を頂いた内容のみ掲載しています。
背景
私は以前よりCTFにかなりハマっており、その関係で2021年の後半頃からペネトレの国際資格OSCP(PEN-200)の受験勉強をしていました。どちらかというと攻撃的なセキュリティ(Offensive Security)の技術や知識を中心に学んでいました。
2022年からの試験範囲がかなり大幅に変わり、ActiveDirectoryに関するハッキング（おおまかにAD侵入→低権限のシェル取得, 権限昇格→DC-Adminを取得という流れ）が主眼となったこともあり、セキュリティは元より社内インフラの構築・運用の観点に興味がありました。
特にCovid19の影響でリモートワークが普及したため、オンプレAD以外のクラウドの知見も必要だと感じていたためセキュリティとインフラ領域のサマーインターンを調べていました。
応募
そんな中、ふとpixiv Insideの記事を拝見したことをきっかけに、インターン募集ページを拝見しました。使用技術が”Amazon Web Services, Google Cloud Platform, Microsoft Azure, Google Workspace, Apple Business Manager, その他各社SaaS”とのことで、社内ITエンジニア枠で応募させて頂きました。
面談の中で、私が興味を持っている技術領域やクラウド分野に関する興味等をお話させて頂きました。
面接経験が浅いこともあり、その後の質問への返答が適切かという所ですごく緊張していました。
数日後に参加させて頂ける旨のメールを頂き、喜んだことを覚えています。
1週目
配属
配属先の部署での長期インターン生の受け入れは初とのことで嬉しかったです。
また業務用PCとしてM1 MacbookAirとSurfaceLaptop4の2台が届き、かなり驚いた覚えがあります。
当初、リモートワークだったこともあり、Discordの雑談サーバーのような雰囲気を感じていました。
課題について
初日に現在のインフラ環境と運用における問題点、それを解決するための課題についてメンターさんよりご説明頂き、調査を開始しました。
具体的な内容としては、Apple Business Managerを利用してAppleIDを社の管理下に置くという内容で、まずは公式リファレンスの参照から始めました。
Apple, Microsoft, Google公式リファレンス自体にも各社色があるな〜と思っておりました。
また大規模な法人の社内インフラを見る機会は今まで無く、知らない用語や技術・プロトコルがあり、公式リファレンスを読むための前提知識を調べるところから始まりました。
特に入社当日、まずIdPとSP, SAMLとSCIM辺りの概念をなにもわからない状態だったので、理解するのが難しかった印象です。
またこういった分野の技術は、かなりニッチで情報源が情シスブログや海外フォーラム(Reddit等)で検証結果を公表されている先駆者(神) or 公式リファレンス以外に少ないという点があります(*1)。
またサービスに寄って異なる部分はありますが、全体的に日本語文献の少なさは感じるところでした。
2週目以降
私は以前自前でExploit検証用のAD環境を構築していたので、上述のSAMLやSCIMといったプロトコルをActiveDirectoryの概念に沿った形で解説する記事がとても理解しやすく感じました。また課題についても着々と調査を行いました。
と同時に大規模な法人における既存インフラの環境を整備する際の難しさを感じていました。
Apple Business Managerの検証内容と詰まりポイント
1. 検証環境の構築
まず検証環境の構築は難しいポイントがありました｡
GWSとAzureテナントは、問題なく検証環境の構築を行い、アカウントプロビジョニングの設定も行えました。
しかしApple Business Manager（通称ABM）の新規アカウント登録は、企業識別のためのD-U-N-S®番号というものが必要で原則として1法人に1つという付与であるため検証環境の作成は見送りとなりました（現状としてABMアカウントは存在するが、MDM以外の用途でほぼ使用されていなかったためそちらを使用）｡
2. アカウント競合問題
ABMとIdPがフェデレーション認証、ディレクトリ同期設定を行った後にIdPに存在するユーザーがABM上に作成（プロビジョニング）され、管理対象AppleIDが発行されます｡
そのため、同じメールアドレスを持つ個人発行のAppleID（便宜上private AppleIDとする）が既に存在しているとアカウント競合が発生します。
private AppleIDのメールアドレスを変更することでアカウント競合は解消できますが、管理対象AppleIDは別アカウントであるため利用していた内容（iCloud, AppStore購入ライセンス等）を引き継げません。
またprivate AppleIDのメールアドレス変更はABMのフェデレーション認証設定後の60日以内に行うように促され、60日以上放置した場合は下記のような形式(*2)でAppleIDが自動更新されます。一応private AppleID所有者本人による手動変更が推奨されています。
- john@example.edu
- john-example.edu@temporary.appleid.com
3. フェデレーション認証が解除できない問題
ABMのフェデレーション認証を解除し､設定しているIdPをGWSからAzureADに変更しようとした際に問題が発覚しました。
当初の想定では、以下の対応でフェデレーション認証設定を解除できる想定でいました。
1. アカウント競合が発生したprivate AppleIDのメールアドレスを変更( アカウント競合の解消)
2. ディレクトリ同期（自動プロビジョニング機能）の解除
3. フェデレーション認証解除←ここでエラーが発生しました
結果として、1度設定したら60日経過しないとフェデレーション認証設定は解除できないシステム上の仕様とAppleサポートから返答を頂きました。
またABMは、1つのIdPとしかフェデレーション認証設定が行えないため60日経過後に検証を進められるよう、課題を進める上で懸念として上がったことの回避手段をまとめたり、検証事項の決定表を作成していきました。
その後､追加課題も同時に進行していく流れとなりました｡
詳細はスライドを御覧ください｡
成長
社内のCSIRTミーティングに参加させて頂いたり、インシデント記録等を見る機会を頂き、自分がこれまでに無かった防御側(Defensive Security)の視点や知見を得ることができました。
また技術面はもちろん、エンジニア業務におけるコミュニケーション能力､
情報が不足しているブラックボックスのような機能の導入を検討する場合に、コードベースで突き合わせることができない上で、
論理的に突き詰め現状の社内環境では、こういった問題が生じるのではという結論を導き、
かつそれを言語化し、情報共有・認識合わせを行うことの重要性と難しさを学生の内に理解できたことが何より大きい成長ではないかと感じています。
また個人的に大切だなと感じたのが図示による情報共有で、自分が理解していないポイントがフローの作成中に出ると「ここってこういう挙動で合っているか？」と振り返るきっかけになり、また第三者に視覚情報として伝わりやすくなる事で言語化すると複雑な議題を、スムーズに理解してもらいやすくなるなと感じました(*3)。
最終発表
そして長期インターンの成果を最終発表の場で発表させて頂きました。
まとめ
私個人の感想として、学生の間に社内IT分野の技術に触れることは重要であるとともに、オンプレActiveDirectoryを仮想環境等で構築し、検証を行うことは比較的ハードルが低いことだと考えています。
下記のようなActiveDirectoryの検証環境構築を自動化するようなPSスクリプトやDocker, Vagrant等もあります
https://github.com/AutomatedLab/AutomatedLab
それに対して、クラウド分野の検証環境（ゼロトラストネットワーク）の構築はやはり学生にはコスト的なハードルがあり、かつ構築方法もイマイチ分かりづらい節があります。
少なくとも私は、こうした理由から社内インフラのクラウド環境を検証用に自前で持つというようなことをしていませんでした。
社内インフラの設計・構築は、将来的に尾びれ背びれが付いていくというか、影響が見えにくい縁の下の力持ち的なところがあると思っていて、「今こういう設計をしました！ → 問題なく利用できてます！」で終わる話ではなくて、長期間その判断が影響を持ち、なおかつrevertもできないというところが興味深くもあり怖くもあるところだなと思いました。
CTFやExploit検証用のAD環境は壊すとrevertすれば済むが、そうした個人利用ではない緊張感がありました。普段勉強している内容だけでは持ちにくい視点や学びがたくさんありました｡
余談として､社内インフラを構築する際にクラウドサービスを利用するとなると大別して、AzureADが社内アカウントの発行元になるか、Google Workspaceがアカウントの発行元になるかという、2通りのパターンがあって、その構成次第で利用できるサービスやAzureADの機能が変わってくるという仕組みやノウハウがたくさんあり面白かったです。
参考リンク
(*1) 先駆者の情報の偉大さ。日本語文献なら神
(*2) Apple公式リファレンス：
https://support.apple.com/ja-jp/HT209349
(*3)エンジニアはもっと図を書こう -
