SASEから広がる理想的なエンジニア環境 今Nextフェーズが始まる 柿田 一 / パーソルキャリア株式会社 2023.05.12 @IT NETWORK Live Week 2023 Summer

1 ■名前 ： 柿田 一 （かきた はじめ） ■生年月日：１９８０年６月２日 今年４１歳 いわゆる松坂世代と呼ばれる年齢です ■出身地：神奈川県横浜市 ■趣味：サッカー、フットサル、スキューバダイビング • 旅行 (東南アジア＋リゾート地方面) ■その他いろいろ： • シンガポールからの帰国後1年が経過し英語力が • だだ下がり中・・・ (業務でも日常生活でも使わない) • 在宅勤務でほとんど座りっぱなしの生活の中、 • -7Kgを達成！ 柿田 一 (Hajime KAKITA) パーソルキャリア株式会社 ガバナンス推進本部 データガバナンス部 兼 テクノロジー本部 デジタルテクノロジー統括部 デジタルソリューション部 COD(Cross Over Director)グループ シニアエンジニア 2020年6月にパーソルキャリア入社。 主に社内のエンジニアのはたらく環境の改善プロジェクトに多く従事をしており、 セキュリティ対策ソリューション導入等のエンジニアリング業務から、社内ルール・ 手続きの改善に至るまで幅広く従事。パーソルキャリア入社前は、メガバンクの グループ内シンクタンクに所属し、約4年半シンガポールに駐在。PMとして インフラ開発案件全般や組織マネジメントに従事。 #ITインフラ #サイバーセキュリティ #データガバナンス #シンガポール 自己紹介

2 一言で言うと 「エンジニアが働きやすい環境を作る仕事」 をしてます 例えば、 • エンジニアリング環境構築 →従来必要であった外部クラウドサービス利用時における情報セキュリティ担当の承認について、 個人情報を取り扱わない事を前提に省略可能とする案件。 悪意を持った内部犯行・情報漏洩を防ぎつつ、正当な業務目的で利用するツールの利用は シームレスに許可する様、CASBやEDRを使ったゼロトラストベースの環境を構築。 • マルチクラウド環境整備 →現状、インターネット経由接続となっている一部クラウドサービスとオンプレミス環境間を専用線で 接続し、よりセキュアに利用出来る様にする案件。 • データ利活用の推進とガバナンス導入 →新規サービスの企画創出時に必要となるコンプライアンス所管部宛の相談について、プロセス・ フローの見直しやツールによる省力化/効率化に加えて、攻めのデータ利活用実現を目的とした データガバナンスの強化策についての検討も推進中。 担当業務 本日メインにご紹介する内容

会社概要 3 パーソルキャリア株式会社 東京都千代田区 1989年6月 1,127百万円 人材紹介サービス、求人メディアの運営 転職・就職支援、採用・経営支援サービスの提供 5,756名 （有期社員含む グループ会社出向中の者は除く 2023年3月1日時点）

パーソルグループについて 4

techtekt（テックテクト）のご紹介 5 パーソルキャリアの「エンジニアリング組織」に所属する 社員のリアルな「はたらく」にフォーカスした オウンドメディア techtekt（テックテクト） 未来の「はたらく」をテクノロジーで創造する 社員、組織、そして文化醸成の過程をつづっていきます。 テックテクト

パーソルキャリアでのSASE導入の経緯 6

これまでの歩みのご紹介 7 https://techtarget.itmedia.co.jp/tt/special/tt230403/index.html

エンジニア組織拡大の歴史 デジタルテクノロジー 統括部立上げ • データとテクノロジーを活用し 売上貢献や効率化、既存事業 支援や新規事業創出を行う 組織(40名規模)の立上げ 2017 テクノロジー本部組成 • 社内のIT関連機能を 一つの本部として集約 2019 BITA担当アサイン • Business IT Architect (ビジネスとITの仲介役) • エンジニア2名にてスタート 2012 サービス企画組織合流 • 新規プロダクトの設計・開発を 行う機能をテクノロジー本部へ 合流 2021 8 外注中心 内製開発強化 SASE導入開始 *既に300名超 100 300 200 エ ン ジ ニ ア 数

9 SASE導入の時点で既にエンジニア組織は300名規模 にも関わらず開発用途の環境が存在しなかった 組織の急拡大に伴い顕在化した課題 歴史的および文化的背景など理由は様々。。。

10 社 内 外 部 内部 ネットワーク 外部環境 境界型防御ベース エンジニア 営業職 スタッフ 顧客情報 個人情報 標準 PC 標準 PC 開発用PC (会社貸与) 社外からのアクセスとなり アクセス元制限により 原則アクセス不可 IdP/SSO インターネット 基幹システム (クラウド) OA環境 申請し承認を得た サービスのみ透過 SaaS PaaS/ IaaS 業務上無関係及び 情報漏洩の可能性ありの サービスは利用不可 企業認可クラウド *情報セキュリティ部門承認 非認可クラウド クラウド ストレージ Web メール等 (オンプレ) リスク判断の為 この承認に長時間を要する エンジニアリング用途の PCで必要な開発環境に 自由にアクセス出来ない 課題 課題 開発用資源(資産管理、テスト実行環境) ソースコード 設計書 等 専用線 アクセス元制限 アクセス元制限 元々の構成 プロキシ 専用線

11 パーソルキャリアでSASEを導入した背景 • エンジニアが効率的に 生産性高く開発が出来る 環境の用意が急務だった • 一部除き殆どの開発資産 はクラウド上 • 今からネットワークも含めて フルスタックで開発用の 環境を一式揃えるのは 実態にも時代にも即して いない。 元の 課題 一方で

12 SASE導入検討時に注意したポイント 我々はITベンダーではなく 人材紹介を主とする 事業会社のIT部門 最新の製品やソリューションを 利用・検証することが主務ではない テクノロジー面でそれを 支える為に何が課題に なっているか改めて整理 以下の2点の解消を 目的として設定 これに資する機能を 導入することを決定 ①外部クラウドサービスの利用 申請時の障壁 ②1による開発効率/柔軟性 の低下

13 SASE導入自体は順調に進んだが と言いながらも・・・

14 蓋を開けてみたら・・・ 実は蓋を開けたら、 SASEと呼ばれる製品の 多くを採用していた・・・ *SASE導入自体を目的に進めた訳ではないのですが

パーソルキャリアの現在地 (2022/4月時点:エンジニアリング環境導入直後) 15 デバイス保護 • EDRによるデバイスセキュティーは実装済でMDM/MAMも検討中 脱VPN • SDPの導入を検討中も一旦スキップ 社内網刷新 • クラウド間の専用線接続準備中 SaaS利用の監視/分析 • CASB導入によりSaaS利用の可視化と不正な情報持出しを制御 社内アプリの監視/分析 • SIEM/SOAR導入し、シナリオに基づく自動検出を実装済 Step1 ID基盤整備 • IdPを導入し、一元的なアカウント管理とSSOを実装 Step2 Step3 Step5 Step6 スキップ Step4 着手済 一 般 的 な SASE 導 入 ス テ ッ プ に 照 ら し た 状 況 引用:日経xTECHウェブサイト(https://xtech.nikkei.com/atcl/nxt/column/18/01311/052200004/)

16 社 内 / 認 可 領 域 外 部 内部 ネットワーク エンジニアリング 環境 個人利用 デバイス・ サービス 境界型防御ベース エンジニア *本番環境保守及び 本番データの取扱時 フロント職 スタッフ CASB+EDR等 VPN/FW(ACL)等 標準 PC 標準 PC エンジニア 個人利用PC リバプロ/SSO でアクセス不可 IdP/SSO インターネット 《新設》 CASB/EDRにより不正な 情報持出を監視/制御 OA環境 顧客情報 個人情報 開発用資源(資産管理、テスト実行環境) ソースコード 設計書 等 基幹システム (クラウド) 専用線 (オンプレ) 専用線 VPN等 SaaS PaaS/ IaaS 企業認可クラウド *事業部側の マネージャ承認 *暫定利用 エンジニアリングPC (会社貸与) 情報漏洩 リスクのある クラウド クラウド ストレージ Web メール等 ゼロトラストによる不正アクセス/情報漏洩防止 SaaS 個人利用 クラウド *個人アカウント によるログイン の抑止等 CASBにより 個人利用と思われる サービスの利用を抑止 従来の申請に代わり利用報告にて利用可 IdP リバース プロキシ アクセス元制限 アクセス元制限 対応後の全体像

SASE導入後のエンジニアリング業務 17

エンジニアの課題は全て解消？ 18 導入開始から早2年が経過 エンジニアは不自由なく開発出来ているか？ SASEの導入状況だけで見ると、 一見イケてる様だけれども、、、

エンジニアの課題は全て解消？ 19 全然まだまだです 具体的にどんな課題が残ったかというと・・・

20 ホールディングスとの共通 インフラ利用と運用依存 エンジニアリング環境構築後の残課題 共通 インフラ データ 本番 アクセス 基幹システムの維持保守に 従事するエンジニアへの手立て データドリブンでのサービス 企画/開発時における障壁 ホールディングスが管理・提供する ネットワーク等共通インフラの利用時に どうしてもお伺い(依頼)と待ちが発生 顧客情報等を含む本番システムは以前 からの環境内に残っておりそれらの維持 保守に従事するメンバーのクラウド利用 プロセスが改善出来ていない 本番データの利用は本番ネットワーク上 のみで許可されており、データ x 外部 ツールでの利用時に課題有り

21 開発プラットフォーム (サーバ・ツール・外部サービス) 取扱データ ソースコード/資源管理 ルール・ ガバナンス 開発 プラット フォーム ・ 環境 関連法令 社内ルール 新規プロダクト開発 パーソルホールディングス・パーソルキャリア標準ルール (コンプラ相談、外部Webサービス利用申請、個人情報取扱申請 他) 個人情報保護法、職安法 等 エンジニアリング環境 (専用キッティング済端末) 標準PC エンジニアリング環境 (インターネットブレイクアウトでSASE制御) 内部本番ネットワーク SASE制御 境界防御 基幹システム保守 限定利用可 *VDI等を経由 利用可能 制約無し *本番環境へはアクセス不可 オンプレ環境 外部サービスは都度利用承認要 外部ソースコード管理サービス ダミーデータ 本番データ 本番移送 ・・・エンジニアリング環境 構築後の変更点 ネットワーク エンドポイント アクセス制御 G共通アプリ (コミュニケーションツール) ホ ー ル デ ィ ン グ ス 管 掌 範 囲 技術スタック的に書いてみると ソースコード管理サービス 結局俺らは 何も変わらずだし ネットワークは ホールディングス依存 あれ？ エンジニアリング 環境からは結局 利用不可？ 本 番 と 開 発 の 壁

例えるならば 22 エンジニアリング環境と本番環境の間の壁は高くそびえたまま 一方でデータの取扱は開発の根幹に関わる部分 例えるならば、 一流の調理器具を揃えたのに肝心の食材が入ってこない状態 まさに宝の持ち腐れ。。。 入荷しません！ いつでも使える状態！

その前に 23 でも データと言っても現状どうなっているのか？

24 ✓ 事業ニーズに対する個別最適で同一環境に対する個別追加開発を進めた為、データ構造が複雑化 ✓ 全体アーキテクチャー設計が無いまま進んだ為、データの流れが見えづらく鮮度もとらえづらい状態 現状のデータアーキテクチャー 分析環境/サービス 業務サブシステム 基幹DB層 インターネット 専用線 どんなデータが流れているか 都度精査が必要

情報セキュリティの目線で整理すると 25 1 データ源泉としての基幹システムは確り守られている この状況を情報セキュリティ目線でリスクと判断された 2 ただしそのデータ活用はクラウドサービスも併用して 行われており、それによりデータが散在する 3 その内の一部はインターネット経由で利用されている

確かに 26 リスクマネジメントの視点で 多大な時間と労力を要する状況になっていた

それに加えて 27 実は現場で声が大きかったのが

28 現場の要望 私が使い慣れたクラウド 何で他のクラウドより利用審査に 時間が掛かるんですか？ そもそも使うクラウドによって チェックの内容や粒度に 濃淡があるのって何でだろう？ 多様性のある エンジニアの集まり

29 【再掲】SASE導入検討時に注意したポイント 我々はITベンダーではなく 人材紹介を主とする 事業会社のIT部門 テクノロジー面でそれを 支える為に何が課題に なっているか改めて整理 以下の2点の解消を 目的として設定 これに資する機能を 導入することを決定 ①外部クラウドサービスの利用 申請時の障壁 ②1による開発効率/柔軟性 の低下 最初にSASE導入を検討した時点に立ち帰り 事業をテクノロジーで支えるエンジニアのパフォーマンスが フルに発揮出来る環境になっているかを再考

30 改めて考えてみると 確かにクラウドファーストを 標榜していながら真の意味での マルチクラウド環境には なっていなかったかも

マルチクラウドは複数の課題に共通するのでは？ 31 マルチ クラウド ネットワーク ホールディングス依存 手続き クラウド毎に濃淡 データ 利用に制限あり 課題 課題 課題 マルチクラウド環境の 整備が諸々の課題の 解決につながるはず

32 であれば 真のマルチクラウド環境を用意しよう。 その際にクローズドな環境でデータを 取り扱える様にしよう *並行して取扱に関するルールを現状に即して見直そう

パーソルキャリアにおけるマルチクラウド 環境導入の取り組み 33

34 背景 クラウドネイティブを標榜しつつも、 一部のサービスがインターネット経由 の為、専用線を経由しないクラウド の利用時に、リスクチェックに手間も 暇も要している 目的 目標 なぜ我々にマルチクラウド環境が必要かを再整理 フラットな真の意味でのマルチクラウド 環境の実現 ・必要なクラウドを自由に選択可能に ・ネットワークセキュリティレベルを上げ 外部サービス利用時のチェック負荷 を軽減しリードタイムも短縮 1. 社内ルールや手続き面の負荷に 起因する利用サービス選択時の バイアスの排除 2. 各クラウド利用時のリスクチェック プロセスの標準化 要は使うサービスにより必要な手続きに濃淡があり 利用者に加え承認者側でも負担がかかっていたのと それによりパフォーマンスを発揮出来ないエンジニアの 負担解消を主たる狙いとしてプロジェクトを始動

35 アーキテクチャ検討 一般的なマルチクラウド環境の アーキテクチャとしては オンプレミス (もしくはプライベートクラウド)を 起点として専用線接続を行う 構成が通常 まずは専用線サービスや 相互接続サービスを 提供している事業者の 調査と比較検討に着手 進め方 やったこと

36 サービスA (DC事業者) • サービスタイプはデータセンター 事業者であるが、同領域では ワールドワイドでNo1の事業者 サービスの将来性や外部 要因での変化に対する 耐性面での安定性を評価 • 将来的なオンプレミスデータ センターの完全廃止を見越し 一部オンプレ機器が残存 した場合にも吸収出来る 選択肢を持つ点も評価 • コスト面も競合対比同等で 対応クラウド数が豊富 サービスB (DC事業者兼回線キャリア) サービスC (回線キャリア) 専用線サービス選定時の評価ポイント • 国内最大手キャリア • 既に同社が提供する専用線を 利用中であれば追加対応のみ にてリーズナブルに対応可能も、 回線コストそもそもが高い為、 今回は見送り • 世界100以上の都市のDCで 主要クラウドへの専用線接続を 提供するサービス • サービス内容・操作性・価格等 サービス面は評価も、回線キャ リアであり、サービス提供の為の DCコロケーションを他社に依存 する点がネック サービスD (DC事業者兼回線キャリア) • ネットワークプロバイダーとしては 最大手の一角 • クラウドサービスへの専用線接続 では後発 • 対応クラウドも他社対比劣後。 • 専用線の帯域調整や接続・ 切断が現時点ではリアルタイム に実施出来ない点が劣後

37 本番セグメント 開発セグメント オンプレDC 本番 DBサーバ 開発サーバ 個社 ルータ 1G回線 適宜チューニング 10G回線 専用線 責任分界点 ホールディングス 管掌領域 サービス事業者DC 回線収容 ルータ 専用線 専用線 専用線 パーソルキャリア管掌領域 キャリア回線 開発NW 本番NW インターネット *今後必要に応じ追加 FW (マネージドサービス) 全クラウド共に本番と開発は論理分割 *現時点インターネット 向け開放は無し 既存専用線 新設部分 限られた端末・社員(非エンジニア)のみ 管理プレーンへのアクセスを許可 コア スイッチ コア スイッチ 導入ソリューションの概要 クラウドA クラウドB クラウドC クラウドD クラウドa • オンプレDCを起点として必要なクラウドと専用線で接続 • 全てプライベートアドレスで管理 POP

ベストエフォート 38 インターネット ルータ ホールディングス全体で 共有 インターネット • 一部を除き、各クラウドサービスの利用時はインターネット経由の為、ホールディングス全体で共有する回線部分では 狭隘が生じる可能性があるのと、インターネットはベストエフォートとなる為、大量のデータ転送を行う分析作業等に ネックが生じている。 ファイアウォール 回線 ロードバランサー キャリアA キャリアB キャリアC キャリアD キャリアE キャリアF 各回線キャリア 各クラウドサービス 以前のクラウドサービス利用時のネットワーク構成 本番セグメント 開発セグメント オンプレDC 本番 サーバ 開発 サーバ 開発NW 本番NW コア スイッチ コア スイッチ 既存専用線 クラウドa クラウドA クラウドB クラウドC クラウドD

39 2021年度 2022年度 備考 9月 10月 11月 12月 1月 2月 3月 上期 下期 マイル ストーン プロジェクト スケジュール 導入マイルストーン ▽社内稟議 ▽オンプレDC内NW設定 ▽発注 <凡例> 本格利用 関係者限定利用 パーソル キャリア作業 ホールディングス 作業 全体作業 接続・ 試行利用 クラウド側 構成変更 運用ルール整備 セキュリティレビュー 費用見積 接続対象 検討/調整 構成fix データセンター関連作業 (ラック/電源調達、回線引込み等) オンプレDC コンフィグ変更

40 現在のエンジニアリング環境の全体概要 ホールディングス 管理クラウド 仮想 デスクトップ 開発オンプレ サーバ群 クラウド サービス群 エンジニアリングPC オンプレDC リダイレクト SaaS群 専用線環境 専用線ネットワーク リバースプロキシ *任意 既存 専用線 Enrollment で使用 インターネット VPN ログ連携 アラート通知 *条件付きアクセスで 許可端末のみ 接続許可 基幹DB クラウドA クラウドB クラウドC 個社管理 *条件付き アクセスで 許可端末のみ 接続許可 SIEM CASB EDR IdP OA環境 IdP

導入時に注意・苦労した点 41

42 コスト回収には幅広い周知と 利用計画/促進が重要 導入時に苦労・工夫したポイント コスト 体制 社内情報セキュリティ担当や ホールディングス担当との調整 アジリティを維持しつつ内部 犯行も起こさせない体制整備 1つ若しくは2つのクラウドとの接続のみ では1対1での専用線接続対比で コスト回収目処が立ちづらい 丁寧な説明による認知を行い 利用を促進する必要有り 社内情報セキュリティ部門や ホールディングスの関係者に対する 丁寧な導入目的の説明や 棲み分けの整理 導入に際して我々にはCCoEの様な 組織や監視を選任に担う部署がない ステーク ホルダー 調整

実際に行ったステークホルダー調整 43 ホールディングス ネットワーク担当 社内情報セキュリティ担当 我々もマルチクラウド 環境導入しようと してますよ！ 目的には共感なのですが 難易度高そうですね リスク対策も気になるし • 認識してます！ • ありがとうございます！ • 我々の取り組みはホールディングス からの独立ではなくあくまでエンジニア の開発の効率を上げることなので 選定基準が大きく異なるはず • 将来的な統合のパスは確り残します • リスク対策は丁寧に定義し対策を 講じてます • 正しく位置付ければ皆さんにとっても メリットの多い取り組みです

①オンプレDC内NW環境 ②専用線サービス提供範囲内環境 ③クラウド側環境 44 個社 ルータ 専用線 サービス事業者DC 回線収容 ルータ 専用線 専用線 専用線 キャリア 回線 インターネット FW (マネージドサービス) 限られた端末・社員(非エンジニア)のみアクセス可 ホールディングス側管掌領域 パーソルキャリア側管掌領域 リスク項目と対策 本番セグメント 開発セグメント オンプレDC 本番 サーバ 開発 サーバ 開発NW 本番NW コア スイッチ コア スイッチ 既存専用線 クラウドA クラウドB クラウドC クラウドD クラウドa POP *現時点インターネット 向け開放は無し

45 領域 リスク項目 対応策 ①オンプレDC内NW • PCA内の環境利用者と結託して悪意のある 設定変更を行うリスク • 設定不備やミスによるセキュリティホールの 発生リスク • 設定変更は従来通りPHD側で行い、環境の 利用者(利益受給者)が設定変更を実施出来 ない様にする。実作業者と承認者を別に設ける 事で単独での設定変更を不可とする ②専用線サービス提供範囲内環境 事業者DC外 • 環境の利用者が自作自演で設定変更を行う リスク (内部犯行) • 設定変更の実施者は環境の利用者とは別に 設け内部犯行を抑止 • 定期的に設定変更履歴やアカウント使用履歴 の監査を実施する運用とする 事業者DC内 • 環境の利用者が自作自演で設定変更を行う リスク (内部犯行) • 専用線事業者のNW内に外部から侵入される リスク • 設定変更の実施者は環境の利用者とは別に 設け内部犯行を抑止 • 定期的に設定変更履歴やアカウント使用履歴 の監査を実施する運用とする • 事業者より内部の詳細構成とコンフィグを徴求し 外部からのアクセス経路が無い事を確認 ③クラウド側環境 • クラウド側にインターネットの口を設け、そこが バックドアとなるリスク • オンプレDC内で専用線接続に通ずる口にFWを 設け不正なトラフィックの侵入を抑止する • 従来通り情報セキュリティGによるレビューを経て、 指示に従い利用を行う事とする リスク項目と対策

46 環境の利用者 設定内容管理者 設定作業実施者 • 依頼に基づく実際の設定変更 • 設定内容の具体化支援 運用監視担当者 • イレギュラー発生時の一次対応 • エンジニアからの依頼に基づく. 環境変更の意思決定 • 本環境を使っての開発実施 • 実開発時のニーズに基づく環境 の設定変更依頼提示 自作自演抑止の為、 兼任不可 異常検知時の共有 その他イレギュラー内容の連携 設定変更依頼 設定変更 依頼 技術面 での支援 自作自演抑止の為、 兼任不可 自作自演抑止の為、 兼任不可 監査機能 (情報セキュリティG) 必要に応じた管理運営状況の監査 目指す管理運営体制

導入により得られたその他のメリット 47 • 昨今、ChatGPTが大きく世間を賑わせており、大手企業でも採用の ニュースが取り上げられています。 • 使う側のリテラシーや倫理面における問題は要考慮ながら、これを独自 の環境で利用出来る場合、意図せず機微な情報をアップロードすること による情報漏洩リスクが下がり、採用に向けての心理的な障壁を押し 下げることに寄与した。

まとめと今後の予定 48

49 まとめ SASEやマルチクラウドといった ビッグワードに踊らされず導入を 検討した目的が何かを失わない ように (導入自体を目的化させない) 導入→即成功はないので、状況 や効果を見ながら適切なフォロー アップを

50 今後の計画 よりエンジニアが 働きやすい世界作り マルチクラウド環境の 更なる周知と利用促進

51 ご参考 https://techtekt.persol-career.co.jp/entry/tech/220926_01

ご清聴ありがとうございました！ 52