【上場前にやったこと】情シス領域での取り組みを公開
この記事は 【初心者優先枠】corp-engr 情シスSlack（コーポレートエンジニア x 情シス）#2 Advent Calendar 2024 のアドベントカレンダー 23日目の記事です。
はじめに
こんにちは！HR techベンチャー企業で情シスを担当しているRaraです。
と、これまで名乗っていましたが、弊社が今年9月25日に上場しまして、晴れて上場企業の情シスになりました😃
関係者の皆様、いつも格別のご高配を賜り誠にありがとうございます。
今回は、せっかくなので、情シス領域で上場準備として取り組んだ諸々のうち一部の内容を公開します。
網羅性がなく恐縮ですが、どなたかの参考になれば幸いです。
アクセス制限
ファイル共有や情報公開、資料展開などにおけるアクセス権限の整理に関して取り組んだことを記します。
①データの外部共有
①−1. リンクの公開範囲を「アクセス権限を付与された人」のみに制限
（リンクを知っている全員へ公開する機能を一律オフ）
みなさまの会社では、外部へ情報を共有する際、従業員の判断で「リンクを知っている全員」へ情報を公開できるようになっていないでしょうか？
資料共有をおこなう際、この設定を適用してしまうと、対象のデータに世界中の誰でもアクセス可能となってしまいます😱
とはいえ「リンクを知らなければアクセスできないんでしょう？そんなに気にすること？ちょっと大袈裟じゃない？」と思いませんか？
愚かな私は正直そう思っていました。
しかし、「リンクを知っている全員」にアクセスを許可しているデータは、Google等の検索エンジンにもインデックスされる可能性があるとか。
メールアドレス単位での権限付与って面倒ですし、誰でも見られるようにしておけば担当者は楽なのですが、リスクを認識せずにやってしまうと取り返しのつかないことになり兼ねません。
共有リンクを発行する際は十分に気を付けましょう。
弊社は、GoogleDriveの設定で「リンクを知っている全員」へファイルを公開できないよう制限をかけました。以下の手順で簡単に実施できます。
GoogleDrive以外にも、オンラインストレージやWikiサイト、ドキュメント管理ツールなど、ほとんどのサービスに似た機能があります。
そして、どのサービスでも、社員の誰かがよかれと「リンクを知っている全員」へ情報を公開しているものです。そりゃあ簡単にできるんだからやるよね🫠
ああ…やっちゃってそう…と思われた方、多いのではないでしょうか。
然るべきタイミングが来たら、ぜひ状況の調査と設定の見直しをしてみてください。
①−2. GoogleDriveで、複数企業への資料の同時共有を規制
社外ユーザー（お客様、取引先など）のメールアドレスに対してアクセス権限を付与する際、気をつけるべきポイントをご共有します。
①−1. の誰にでも閲覧できてしまうリンクの共有とは異なり、今回はアクセス権限を付与された個人しか情報を閲覧できないため、セキュアな運用に見えます。
問題なのは、外部ユーザーへの権限付与時に送信される「〇〇からフォルダが共有されました」という通知メールの送信先情報です。
実は、GoogleDriveで複数のユーザーへアクセス権限を一括付与すると、CCに権限付与対象者のメールアドレスが含まれた状態で通知メールが送信されてしまいます。
直接契約関係のないお客様同士が、互いに通知メールのCCに含まれるメールアドレスを確認できてしまうのです。
通知メールは権限付与後にGoogleから自動で送信されるため、手動でBCCに変更する等の対応はできません。
これを踏まえ、複数企業への資料の同時共有は規制する運用としました。
①−3. 外部共有専用フォルダの運用
弊社では、GoogleDriveの共有ドライブにおいて、外部共有用フォルダと社内限定公開フォルダを完全に分けて運用しています。
外部共有用フォルダにはそれぞれ適切な管理者(プロジェクトオーナー、役職者など)を設定し、管理者の承認を得ない限り、一般社員は外部へフォルダ・ファイルを共有できません。
適切なフローを経て外部への情報共有がなされていることを証跡として残すため、Slack上でワークフローの整備をおこないました。
①−4. リンクを知っている全員へ公開する用途としてDroopboxを整備
①−1. でGoogleDriveにおいて「リンクを知っている全員」へファイルを公開できないよう制限するにあたり、「リンクを知っている全員」へ情報を公開するためのツールとしてDropboxを導入しました。
Dropboxのアカウントを情報の公開が必要な担当者に絞って運用することにより、無闇矢鱈に「リンクを知っている全員」へ情報が公開されることを抑制するための施策です。
以下の通り、用途別に使い分ける運用としました。
Google Drive:
取り扱う情報：社外秘情報、非公開情報
共有方法：対象者メールアドレスに対して、責任者承認のもと適切なアクセス権限を個別付与
Dropbox:
取り扱う情報：公開情報、一部の機密レベルの低い情報（セミナー資料など）
共有方法：リンクを知っている全員へ、公開リンクを共有
①−5. SharePoint /One Drive 外部共有機能の制限
①−1. と内容は同じで、共有できる対象を「すべてのユーザー」から「自分の組織内のユーザーのみ」に変更しました。
Google Workspaceをメインで利用していると見落としがちなのですが、Office365のライセンスが付与されたユーザーは自動的にOne Driveを使えるようになります。
デフォルトで外部共有可能な設定になっているので、Microsoft環境の方が使い慣れている社員などは特に、気軽に使って共有してしまうかもしれません。
Excel /Word /PowerPoint等の利用を目的でOffice365を利用しているとなかなか気付けない領域ですよね。
②ステークホルダーとの連携
①では、社員が外部へ情報を共有するうえでの設定や運用について記しましたが、社内だけでなく、社外取引先、委託先、パートナー企業様などにおける情報の取り扱いにも注意が必要です。
社内でストレージの共有機能を制限していても、社外の環境までは制限できません。
情報の保管場所を含むセキュリティ運用について、社外の関係者においても注意いただくよう、十分な連携が必要です。
③GitHub Google検索でパブリックになってないか
この項目は私でなく上長が実施したのですが、ぜひ共有したいというありがたい提案を受け、記事に盛り込みました。
「GitHubの公開権限については留意はしていたものの、会社契約のGitHub Organization外で、個人アカウントや業務委託アカウントが不用意にレポジトリ等を公開していないか気になった」とのこと。
弊社では過去10年ほど前から長くGitHubを利用しており、その間に誰かが公開すべきでないソースコードを公開したりしているのでは？と考えたわけですね。
そして以下の検索文で公開レポジトリがないか検索した結果、不要なレポジトリ公開が1件見つかりました💀
inurl:github.com AND (自社サービス名① OR 自社サービスドメイン② OR "自社サービス名②" OR "自社サービス名①" OR 自社社名 OR 自社GitHub Organization名)
会社用のアカウントを綺麗に整備できていない企業では特に、不要な公開レポジトリがないか検索して確認してみてください。
④端末のアクセス制限
「私用端末から会社のアカウントや業務情報へアクセスしてはいけません」というルールは、多数の企業に存在していると思います。
そのうえで物理的に制限をかけることがここ数年の課題となっており、悪戦苦闘しながら向き合ってきたお話を共有します。
④−1. 私用スマートフォン端末のアクセス制限
手段として、Jamf Pro × Google BeyondCorpを統合し、CAA(コンテキストアウェアアクセス)機能を利用しました。
以下、クラウドネイティヴさんが公開してくださっている記事が大変分かりやすく、参考にさせていただきました。
設定自体は簡単なのですが、なかなか思い通りに動いてくれないことが多く、それはもう何度も何度もJamf ProベンダーであるTooさんにご相談を重ね、助けていただき、試行錯誤の結果なんとか運用が回るようになりました。
当初、「対象デバイスにGoogle Device Policyを入れないとGoogleWorkspaceから端末のアクセス制限をかけられない→Jamfを導入している以上、Google Device Policyは同端末内に共存できない→Jamfを消すわけにはいかない→つまり制限できない→むり！」と思っていたため、この記事との出会いは革新的でした。
上手くいかなかった期間、根気強く対処策を検討いただき、親身に向き合ってくださった関係者の皆様に心より感謝申し上げます。
本当にありがとうございました。
④−2. 私用PC端末のアクセス制限
PCに関しては、アクセス元IPアドレスを限定することによりアクセス制限をかけました。
弊社ではすべての社用端末にNetskopeを導入しています。
Netskopeが有効化された端末の接続元IPアドレスと、社内ネットワークのIPアドレスを用いて、CAA(コンテキストアウェアアクセス)により業務情報へアクセス可能な端末を絞りました。
メールの誤送信対策（Gmail）
世間では、脱PPAPが進んでいます。
弊社でも、以前はメールにファイルを添付する場合パスワード設定が必須でしたが、必須としない運用へルールを改定しました。
その反面、誤送信対策を十分に施すことは、より強く求められるようになっています。
ここでは、簡単に導入できるGmailの誤送信対策を2点ご紹介します。
①−1. GoogleChromeで、誤送信防止用の拡張機能を追加
誤送信防止の拡張機能を追加すると、メール送信前に必ず以下の項目をダブルチェックする工程が挟まります。
送信元アドレス
送信先アドレス（社内アドレスと社外アドレスは別の色で表示され、目視で違いが分かりやすくなっています）
To
Cc
Bcc
件名
添付ファイル
それぞれの項目が正しいことを確認し、1つ1つにチェックを入れないと送信できない仕様です。
無料で簡単に追加でき、大きな効果が期待できます。
お手軽でおすすめの対策ですので、ぜひご興味のある方は追加してみてください。
個人単位で追加するほか、組織全体に適用することも可能です。
①−2. デスクトップ版のメールアプリ利用制限
①−1. でGoogleChromeの拡張機能を紹介しましたが、デスクトップ版のメールアプリには拡張機能は適用されません。
そこで、より誤送信防止を徹底するには、メールアプリの利用を制限し、GoogleChromeからメールを利用してもらうことで、確実に送信前の情報をダブルチェックできる環境を整える必要があります。
弊社では、MDM（モバイルデバイス管理）からデスクトップ版のメールアプリの利用を制限しました。
②送信タイミングを5〜30秒遅らせる
Gmailには、送信ボタン押下直後にメールを送信せず、指定した秒数が経過するまでは送信を取り消すことができる機能があります。
万が一誤字や間違いがあった場合も、送信ボタンを押した後、送信前に気付ける可能性が高くなります。
入退室・勤怠管理
①電子錠の運用
電子錠の導入は、本格的な上場準備着手より前におこないました。
個人に紐づく社員証のような位置付けでセキュリティカードを社員へ配布し、カードがないと執務スペースへ入室できないようにしています。
執務スペースの情報資産を守る意味でも電子錠は重要ですが、勤怠管理においても有効活用できます。
IPOで提出を求められる勤怠ログには、業務端末稼働ログの他、このような入退室ログも証跡として利用可能です。
②オフィスカメラを導入
オフィス出入口およびフロア全体を映すためのオフィスカメラを設置しました。
カメラの設置は必須ではありませんが、万が一電子錠に不具合が発生した時や、何かトラブルがあった時のログ確認手段として有効です。
社内での落とし物が見つからない時などにも、地味に活躍しています。
また、ISMS 27001:2022では、物理セキュリティ対策として監視カメラなどを含めた管理策が新規追加されました。
なんとなく物理セキュリティを強化しようと設置したカメラが、新規格対応をスムーズにしてくれました😊
③夜間休日のネットワーク制限
適切な勤怠時間の管理（稼働時間を正しく申告すること）は、IPOにおいて厳しく見られるポイントの1つです。
業務端末の通信ログ、オフィスの入退室ログ、業務アカウントへのアクセスログなど、あらゆるログが業務実施の証跡となり得ます。
勤怠は正しくつけてね！と社員へ周知徹底をおこなうことは大前提。
加えて、「虚偽申告できない環境」を技術的に整備することも重要です。
弊社では、NetskopeのReal-time Protection機能を用いて、夜間休日に業務端末がインターネットに接続できないよう制限しました。
残業申請や休日出勤申請をしていない社員が当該時刻に業務端末を利用しないことは当然であるべきで、より確実な管理手段としてインターネット遮断を選択しました。
ほかにも管理手段は多数ありますので、企業文化や社員の勤怠状況に応じた適切な選択の検討をおすすめします。
別の企業の情シス仲間からは、ラクローで勤怠管理を強化したという話をちらほら聞きました。
制限が必要な理由を社員へ十分に説明した上で、システム制限を手段として選択することは、時には重要かもしれません。
SaaSアカウント管理・コストカット
最後に、最もRaraが工数をかけた、単純だがなかなか一筋縄ではいかないSaaS管理についてお話しします。
①アカウントの棚卸し
各種SaaSアカウントの棚卸しは定期的におこなっているものの、上場準備期間に関しては、より細かく、厳しく、数ヶ月間かけて徹底的に高密度の棚卸しをおこないました。
通常の棚卸し：
一定期間、サービス利用履歴のないユーザーをピックアップ
利用状況をヒアリングし、不要な場合は削除・権限停止
終了 ※部署異動や入退職に伴う棚卸しは月次で実施
上場前の棚卸し：・
そもそも、そのサービスは業務上利用必須なのかを利用部署へ細かく確認
どの業務に、どのような用途でどう利用しているのかヒアリング
他の類似サービスに代替できないか提案・相談・検討
場合によっては移行・統合スケジュールと手順を準備し案内
移行・統合を実施（とても大変）
サービス利用者全体を見直し
どの業務に、どのような用途でどう利用しているのかヒアリング
業務利用が必須でない社員たちから、期間の提示や代替策の提案をしたりしなかったりしながら、ライセンスを剥奪
ライセンス数を最小限に削る
結果ライセンス不足に陥るが、必要に応じて少量ずつ追加購入して調整する
「利用必須」であることの判定はなかなか難しく、アカウント種別を変更したり、アカウント自体を停止したりしたことで、業務効率が下がってしまった社員もいました。
上場前ってこんなにあれこれ削らなきゃいけないのか…と頭を悩ませた時期もありましたし、反省点は多々ありますが、結果、大変良い経験になったと思っています。
社員に寄り添いつつSaaSコストを目標数値に近付けるという高難易度課題と向き合った経験は、必ず今後の運用に活きます。
②ベンダー乗り換え、年契約への切り替え
コストカットの観点で力を入れたポイントの1つは、SaaS購入先の再選定です。
昔から直販で購入し続けているサービスも、ベンダー経由の購入に切り替えると大抵お安くなります。（ならないこともあります）
既にベンダー経由で購入している場合は、既存購入先のベンダーさんや、別のベンダーさんへ相談してみるとお値下げいただけたりします。
無茶なご相談に乗ってくださったベンダー様方には、感謝感謝の限りです。
いつもありがとうございます。
また、契約期間が月単位の場合、年契約に切り替えることで1ヶ月あたりの利用料金が安くなることが多いです。
長期利用が前提のサービスは、可能なら思い切って年契約に切り替えてしまいましょう。
③SaaSコンプライアンスの準拠
例えば、共用アカウントを明示的に禁止しているサービスにおいて共用アカウントの利用が明らかになると、IPOの基準に引っかかります。
ほかにも、従業員数が何人以上になるとアカウント有償化が必須といったサービスも存在します。（Dockerは、従業員数250人以上、年間売り上げ1000万ドル以上の組織において、無料プランの利用をNGとしています）
上場有無に関係なくルールを守ることは当然であり重要ですが、上場を目指す場合は必須です。
SaaSコンプライアンスの違反がないよう、利用ルールはよく把握して運用するようにしましょう。
終わりに
あれこれ書き連ねましたが、これがすべてではありません。
他にもたくさん必要事項はあり、また、それらを実現するための多種多様な手段があります。
今回は弊社の取り組みをもとに記事を書きましたが、今後、ぜひ他企業の取り組みも参考に、網羅的な情報掲載ができたら素敵だな〜と考えています。
（Raraから声をかけられた情シスの方は、ぜひご協力をお願いします…！）
上場準備に限らず、GoogleWorkspaceのベストプラクティスとか、知っておくべき細かい設定とか、何らかのお役立ち情報を今後も発信していきたい所存です。
初めてのアドベントカレンダー参加でしたが、楽しく執筆できました✨
貴重な機会をいただきありがとうございました！
皆様にまた、情報をお届けできることを楽しみにしています。
良いお年を！