ID:78450さん

# 職務概要 コーポレートセキュリティを中心にプロダクト・サービスも含めた社内のセキュリティ全般をメインの業務として担当、サブでいわゆる情シス業務を担当しています。 ## チーム構成、業務環境 - トップはCISOで、プロダクトセキュリティ中心のチームがマネージャーと担当各一人ずつ、コーポレートセキュリティ中心のチームがマネージャー一人と私一人になります - 誰が何を中心に担当するということを一応決めてはいますが、少人数ということもあってチームの壁を越えて意見を出し合う機会が多いです - リモートワーク主体（どうしても出社しなければならないとき以外、出社しない。おそらく、入社初日以来出社していない人もいる）で個人情報を多く扱う、各種法規制も受ける事業を行っているため、セキュリティおよび法令順守に関してはかなりシビアな環境で真剣に取り組んでいます - CEOが他社のセキュリティインシデント事例に社内チャットで言及・発信するくらいセキュリティに注意を向けていて、期待と良い意味でプレッシャー（真剣に取り組む動機付け）を感じながら日々業務に取り組んでいます ## セキュリティ業務 - クライアント企業様からのセキュリティチェックシート回答 - クライアント企業様のセキュリティ監査対応 - セキュリティチェックシートや監査対応の感触（設問内容や監査対応で対面でやり取りした時の先方の反応）からクライアント企業様のセキュリティニーズを探り、社内に還元しています（私が自発的に取り組み始めました） - 過去（入社前も含め）の監査の議事録から先方の関心事を読み取り、再度の監査の際の回答の材料を揃えて準備するようにしています（私が自発的に取り組み始めました） - 例えば、次のようなことです（議事録の予定稿にあらかじめ書いておく） - 回答で引用している規程類のアップデートを確認し、整理しておく - 質問があった数字の最新の数字を確認しておく、など - 社内のセキュリティに関するルールメイク、規程類アップデート - 最近はとくに生成AI系のツール／サービスの利用ガイドラインの策定に取り組んでいます - 現職の会社はリモートワークをメインにしており、そのためのセキュリティ対策にも注力しています - 社内に導入するツールやサービスのセキュリティチェック - 基本方針は、安全に使ってもらうためにどうしたら良いか、というのを伴走型で支援しています - ただ、あまりにもダメなモノはダメ、としたこともあります - 新規サービスのセキュリティ設計伴走 - 既存サービスのセキュリティ改善提案 - 既存サービスのセキュリティ診断、ペネトレーションテストの実施ベンダさんの選定から結果検収までの対応 - 社員向けセキュリティ教育コンテンツの作成、啓発活動 - 社内で起きてしまったインシデントやヒヤリハットの対応 - 幸い私が入社してからは大きなインシデントは発生しておりません - 小さなインシデント、ヒヤリハットは何件か経験しました - その際、ほとんどのケースで私が最初に対応しています - ひとがやりたがらないことを積極的にやる、というポリシーで取り組んでいます ## 情シス業務 - 新入社員のPCのキッティングとオンボーディング - Macを利用しており、私が引き継いだ時点でMDMでかなりの部分が自動化されていました - 入社当日のPCのセットアップ支援 - 以前は入社する人も少なく、マンツーマンに近い状態でやれていたようなのですが、最近は入社する方も増え、ドキュメントの充実に力を入れています - 各種SaaS管理 - 主な管理しているSaaS - Google Workspace、Slack、Zoom、1Password、JamfPro、Microsoft 365 ## 利用している技術 - Google Apps Script - 利用目的：各種業務自動化・効率化 - 担当フェーズ：非エンジニア職の方から漠然とやりたいこのご相談を頂き、そこからニーズの深堀、本当にやりたいことの実現方法の模索を伴走し、実装方法の検討、設計、実際のコーディングまで一貫して担当しております。 - 主な実績：利用しているSaaS間の連携、Slack botの作成などがあります。 ## 準拠している規格、業界標準等 - ISMS - ISO/IEC 27001 - ISO/IEC 27017 - プライバシーマーク - JIS Q15001

管理職の監督と部署間の調整はあるものの、実働はほぼ私一人で行いました。 # プロジェクトのゴール 上場に向けて残業代未払いがないことを労務監査で示せるようにすること 具体的には、既存の勤怠管理システム（社員が出退勤の打刻をしているシステム）の記録と、PCの起動・停止を自動的に記録するシステム（エージェント導入型のSaaS）の記録を突き合わせて、正しく勤怠を把握して給与が適正に支払われていることを示せるようにする。 # 技術的な条件 ## 既存の勤怠管理システムに関する条件、機能、制約 - 給与計算と密結合で変更したくない（できない） - 打刻データをCSVで出力することはできる - APIは提供されていない ## 新規導入したPCの起動・停止記録時刻システムの機能、制約 - 自己申告の出退勤打刻データをCSVで取り込むことはできる - 自己申告の出退勤打刻とPCの起動・停止時刻の差異を計算することが出来る - 自己申告の出退勤打刻とPCの起動・停止時刻に1分でもズレがあると異常値と判定される＝ここが自社のニーズと合わない # 会社の方針 5分以内のズレは許容し、それよりもズレが生じていた時に、自己申告の訂正または問題ない旨の理由の記載を求めることした。 # 私のアクションとアウトプット ## PC起動・停止記録時刻システム導入前フェーズ - 労務担当者から相談を受け、目的とそのために実現したいことを整理し具体化しました - 市場にあるプロダクト、サービスを調査し、ニーズを満たせそうなものをピックアップしました - ピックアップしたものの資料請求、営業さんへの問い合わせを行い、さらに候補を絞りました - 最終的に試験導入するサービスを一つ選定しました ## PCの起動・停止記録時刻システム導入初期フェーズ - PCにインストールするエージェントのMDMでの配布を検討するものの、ベンダさんから非対応との回答でした。 - 全社員向けに、エージェントのインストール手順の導入ドキュメントを作成しました。 - 幸いなことに手順書が分からない、手順通りにいかないなどのお問い合わせは発生しませんでした。 - 手順書を読んでくれない方は少数でしたがいらっしゃって、手順書を案内して解決しました。 - 既存の勤怠管理システムから出力した勤怠データCSVを、新規導入したシステムに取り込ませるためのフォーマット変換を行うGoogle Apps Scriptを作成 - 列（項目）の取捨選択、並び替え、日付や時刻のフォーマットの変換処理を実装しました。 - 実装していてSpreadsheetのAPI呼び出しが遅いことに気づき、極力データをまとめてAPIに渡すことで処理の高速化を図りました。 ## PCの起動・停止記録時刻システム本格導入フェーズ - Google Apps Scriptで次のような機能を実装しました。 - 出退勤打刻とPCの起動・停止時刻のズレが会社が定めた5分を超過している社員・日付を抽出する機能を実装しました - ズレの超過があった社員とその上長にメールでアラートを送信する機能を実装しました - ズレの超過があった社員にSlackでアラートを送信する機能を実装しました - 労務からの要望で、社員がズレの理由を記載するGoogle Spreadsheetを社員ごとに用意しました - イニシャルで100弱のスプレッドシートを作る必要があり、ひな形を一つ作ってそのコピーを作成、社員番号と氏名をベースにリネームする処理を実装して対応しました - スプレッドシートの編集権限を当該社員に付与し、閲覧権限をその上司に付与する処理も同時に行いました - その応用で、新入社員対応で人事データを取り込み、当該社員のためのスプレッドシート作成、権限設定を1クリックで実行できる機能も実装しました - 月次の締め作業のために、全社員がズレが5分を超過していた日の理由を記載したor自己申告の打刻を修正したのを集計する機能を実装しました ## 追加対応 - 深夜勤務を申請する制度が新設され、深夜時間帯にPCが稼働していた場合に申請が出ているか、突き合わせる機能を実装しました ## 使用した技術 - Google Apps Script （GAS） - Google Spreadsheet ## 私のアウトプット - Google Apps Script 計1000行代後半（コメント込み） - 労務の方向けの作業手順書と作業用シート # 所感 Google Apps Scriptを本格的に使うのはこのプロジェクトが初めてでしたが、Google社が公開しているリファレンスドキュメントをざっと眺めて必要なメソッドにアタリを付けて、一読して使い方を把握することができて、比較的スムーズに実装を進めることが出来ました。 それぞれのシステムが出力するデータをみて、何をどう処理すればよいか、というのは悩まず設計できました。

# プロジェクト概要 新卒社員および中途未経験の社員向けの教育コンテンツ作成と受講者の支援 # 私のアクションとアウトプット - Linux、セキュリティ、Microsoft Azure、ネットワーク分野について、初学者向けの教育・研修コンテンツを作成しました。 - 情報処理技術者試験やベンダ試験などの試験範囲などを参考にしました。 - IPAや官公庁が提供している資料、Microsoftが提供している学習コンテンツなどを中心に紹介し、取り組みの観点や目的、背景などを説明し、ゴールを設定しました。 - 公開資料で足りない分は、休日に大型書店に出向いて適切と考える本をチョイスして経費で購入できるよう調整しました。 ｰ 全受講者の日報を確認し、積極的にフォローしました。 # 所感 中途入社した会社で、教育も手厚く人の定着もよい会社でしたが、買収されて方針や環境が激変してしまい、せっかく作ったコンテンツが1年だけしか使われなかったのが残念です。

# プロジェクト概要 - IDS/IPS/WAF による企業向けマネージドセキュリティサービスの運用 - クライアント企業数100社程度 # 私のアクションとアウトプット ## 通常の運用業務 - ベンダさんからリリースされたシグネチャが対応する脆弱性のリサーチと評価 - 評価結果に基づき、シグネチャの適用方針の提案、決定 - 新規クライアント企業様向けのアプライアンスのセットアップ - 月次のログのバックアップ作業 ## 業務改善 ### ログのバックアップ作業の自動化 - 私がジョインするまでは、毎月3-4人日かけて手作業でログの圧縮や整理、DVD-Rへの書き込みを行っていました - 私に業務が引き継がれ、初月は従来の方法を踏襲しましたが、待ち時間にスクリプトを作成し、翌月からメディア入れ替えを伴うDVD-Rへの書き込み作業以外を全て自動化しました。 ### クライアント企業様向けレポートWebシステムのリプレイス - 開発自体は外部のベンダさんに依頼しましたが、次のようなことがありました。 - Webシステムを稼働させるサーバの機器選定・サイジングとLinux環境の構築を行いました（当時はオンプレでした）。 - 外部からの脆弱性診断で発見できなかった脆弱性を発見してベンダさんに修正提案をしました。 - 将来的にパフォーマンスの問題が生じる（ひとつのディレクトリに数十万ファイルが作られうるため、一部機能がタイムアウトする）ことに気づき、ベンダさんに修正提案しました。結局、運用でカバーすることになりましたが、それの自動化もしました。 ### SOC監視システムのバージョンアップ - 24/365での監視業務は別部署が行っていましたが、彼らが使うシステムのバージョンアップを行い、次のようなことがありました。 - Linuxと複数のOSSとベンダのマネジメントシステムの組み合わせで構成されていました。 - ベンダのマネジメントシステム自体はベンダさんの案内通りで特に問題なくこなせました。 - OSS部分が曲者で、メインの設定ファイルが各ソフト巨大な1ファイルでいわゆる秘伝のタレになっていました。 - OSSのバージョンアップ（メジャーバージョンが2つくらい上がるものもありました）で設定ファイルがそのまま移行できず、秘伝のタレを読み解き保守性を考慮して設定ファイルを作成しなおしました。ただ、そのことよりも、その後の設定の試験に膨大な時間を費やしました。 # 所感 ネットワークの部署が流行に乗ってセキュリティにも手を出したプロジェクトで、チームメンバーのほとんどがネットワークは分かるけれどLinuxは分からない、セキュリティも何となくしか分からないといった状態でした。私が少しそういったところも出来る、というのが分かった途端、あれもこれもといわゆる技術的負債を押し付けられてしまいました。教育込みで巻き込もうとしましたが、みんな我関せずの姿勢を固持し、私だけ疲弊していきました。 本籍はエンジニア派遣の会社だったのとそういった状況だったので、プロジェクトを変えてもらうよう掛け合いまいましたが取り合ってもらえず、最終的にメンタルを病んでしまいました。

# プロジェクト概要 データセンタ事業の会社で導入するサーバハードウェア（年間導入台数1000台以上）の新規導入から廃棄までの一連の業務の設計と改善。 ## 業務内容 機器構成の選定に始まり、ラック搭載、ネットワーク接続、OSインストール、監視、ハードウェア故障対応、サービスでの使用終了に伴う使いまわしのための初期化、最終的な廃棄などなど、ライフサイクル全般、ゆりかごから墓場まで、業務全般を設計し、実働部隊のための手順書を作成しました。 ## 主な実績 - 準備から後片付け、他部署との連携など分かりやすい手順書の作成に努め、私が担当していた期間中に手順書が原因の事故は起きませんでした。 - 担当部署が定められていない業務があることに気づき、手順を立案して担当可能な部署に提案して採用いただけました。 - 故障・トラブル対応の記録を分析し、次の問題があることを特定してメーカーさんにフィードバックしました。 - 特定機種の特定パーツの品質がメーカーさんの基準を満たしていないことを特定しました（故障割合が同メーカーさんの他の機種と比べて多く、発生時期も早い）。 - Firmwareのバグを特定しました。再現条件を整理してメーカーさんにお伝えし、修正に繋げています。 ## 苦労したことと工夫したこと - 業務で必要になる技術の範囲が広くて連携する方々の専門性はそれぞれ異なり、さらに資産管理など専門がITでない方も関わることから、相手に専門や関心事項に合わせて調整を進め、全体最適を図りました。 - 24/365の対応や大量の定型作業などが多く決してスキルが高いとは言えない人も多くアサインされており、そういった方たちでも、誰が何回やっても同じ結果が残せる手順書を作成することを心掛けました。 ## プロジェクトを通じた学び - テクニカルなコミュニケーションや調整能力、手順書作成能力は相当鍛えて頂きました。 ## 使用した技術、プロダクト等 - サーバ：HP社製、DELL社製がメインでした - OS：Linux