この記事では、以下のようなチームを想定して、お金と手間をできるだけかけずにそこそこセキュリティを向上させることをまとめようと考えています。そんなんじゃだめだ！とか、こういう場合は漏れませんか？というコメント大歓迎です。
想定するチーム
- 営業やCS、マーケの人など全職種含めると30人前後あるいはそれ以下で、Webサービス（アプリ含む）開発を行っている
- 副業人材も多く、半数のメンバーは会社支給でないマシンを使っている
- それらのマシンは他社の業務でも使用されている
- Macが多めだがWindowsもいる
- 基本的に業務データはクラウド上にあり、PCローカルにあるのは開発途中のデータ、Biz/バックオフィス系のドキュメント、重たいデザイン系データ程度。自社データセンターや、オフィスネットワークでしかアクセスできないサーバはない。
- メインの業務ツールはGoogle WorkspaceとSlackとGitHub
- 予算はそんなにない。Slackもケチって一部メンバーはシングルチャネルゲストにしていたり、Google workspaceアカウントも付与していないため、個人メアドで参加している。
- 専任の情シスはいない。サーバ側のエンジニアが兼務していたり、アカウント管理はBiz側の人が兼務していたりする。テック系の役員が一応全部承認している。
- ほとんどの業務をSaaSというかオンラインで行っており（Figma, Apple dev center, Google Tag Manager, AWS or GCP/firebase or Azure, Sendgrid, Sentry）細かく数えると一部メンバーだけでもログインする先は20を超える。
- 提供サービスの顧客はまだそこまで多くない、（セキュリティ事故でない）半日程度のサービスダウンが起きても謝れば許される程度。
- ただしここでは、その会社が開発するWeb/Mobile app自体のセキュリティはスコープ外。
どこから手を付けるか
基本的には、潜在的な汚染ゾーン（＝一般エリア）と、クリーンルーム（＝セキュリティエリア）を分けるところからやりましょう。特に重要なデータ・システムを取り扱うモノや経路をセキュリティエリア、それ以外を一般エリアとして区別します。（いわゆる情報資産の整理です）
◆クリーンルームで取り扱う情報
- 顧客（とくに法人ではなく個人）の情報
- その個人情報を取得・保管するシステム
- アプリケーション以外にも顧客リストの乗ったGoogle Spreadsheetとかもね
- お金を取り扱うシステム（Stripe、ネットバンク）
- 共有アカウントの管理システム（パスワードマネージャなど）
- インフラにかかわる情報（クラウドの管理者権限・ドメインの管理権限・メイン業務SaaSの管理権限）
- 本番サーバ、モバイルアプリの公開など本番系システムの管理権限（AppStore Connect / Google Play Console）
- アライアンス先など他社から受け取った機密データ、資金調達など運転資金に直結する情報
- 関係者の機微情報（マイナンバー、健康に関する情報など）
◆一般エリアで取り扱う情報
- それ以外全部
- たとえば、開発中のソースコードや、未発表の新機能の企画、ある程度の営業数値などはこちらに含めざるを得ないものとする
一般エリアはどの程度守るか
まずは一般エリアから考えます。セキュリティでは一番手薄なところが突破されるのが定石なので、以下のようなケースを考えてみましょう。
副業で新しく入った開発者のAさんは、個人のPC、個人のGmail、個人のGitHubで週10時間参加してくれているサーバサイドのエンジニアです。Slackの通常メンバー、Google Driveのいくつかのフォルダに招待し、AWSの開発用アカウントを発行、GitHubの権限を一通りつけて、その他開発に必要なSaaSの共有アカウントと、共有のAPIキーを含んだ.envファイルを渡しています。
ある日、些細なことがきっかけでこの会社の役員とＡさんが喧嘩になってしまいました。あまりに傷ついたＡさんはヤケになり、迷惑をかけてやろうと考えました。
手始めにＡさんは競合の会社に友達がいたため、情報を横流しし始めました。GitHubのソースコード一式、Google Driveの共有フォルダ、開発用SaaSに登録された情報などです。
さて、ここで考えられるポイントと、どこまでを許容するかを考えてみましょう。
システムで防ぐのか、それ以外で防ぐのか
セキュリティの考え方では「リスクの大きさを見積もって、そのリスクの許容度に応じた対策をする」ことが重要です。情報漏洩などのセキュリティ事故により、脆弱性が発見されるかもしれない、営業機密が奪われるかもしれない、未発表のネタが外に出てしまいマーケティングが失敗するかもしれない、取引先や投資家から信頼を失うかもしれない。
一方で、これらすべてをシステムで防ぎながら生産性高く業務するのは相当難しくコストもかかります。人間が作業する以上、脳に蓄積された情報はどうしようもありませんし、画面をスマホで録画されてOCRにかけられれば大量の情報も一定の精度でコピー可能です。
本当にシビアな情報（大量の個人情報や機微情報）を扱う際は専用の監視部屋で作業させるといった方法はありますが、リモートワークで自宅作業可能な段階で、システムでできる対策には限界があるのです。
システム以外の対策
そこで、まずは教育と抑止です。業務委託契約時に秘密保持などを含めるのは当然ですが、あらためてセキュリティに関して意識してもらうよう啓蒙することが必要です。さらに、後述するようなチェック体制を作ること、そういった仕組みがあることを周知することで、「悪いことをしても自分のリスクが高いしやめておこう」と感じさせることができます。あとはマネージャ層の心がけも大事で、エンジニアに限らず関わってくれる人たちを大切に扱うことは最も大事なことです。
そもそも、性悪説にもとづいて設計しなくても、大多数の人は悪意なく「うっかり」やらかしてしまいます。お気に入りのスクショ撮影Chrome拡張が、いつの間にか闇の組織に買収されてマルウェアになっていることなんてよくありますしね。
一般エリアはあくまで「最後はあきらめる」領域
小さなチーム、予算のないチームにとって、ない袖は振れぬところがあると思います。あくまで「情報漏洩しないこと」が目的ではなく「情報漏洩によって起きるリスクを低減すること」を主眼とすると、以下のような代替策が取れるのです。
- 超いけてる新機能アイデアが競合に漏れちゃったけど、スタートアップだし実行速度で勝負！一気に作って宣伝して後発を出しにくくしよう！
- 法人のお客様に誤送信してしまったけど、関係性を普段から築いてるからめちゃくちゃ怒られるだけで済んだ
- 共有アカウントで使ってるSaaSの情報がうっかり全削除されちゃって困ったけど、そもそもデータ少ないし3日3晩でゼロから作り直した
誤解の無いように言うとノーガード戦法とはちがいますよ。リスクを見積もった結果、ある程度低減策を実施してなお起きたものは事後対策すればいいと事前に話し合うという意味です。
全エリアでやるべき対策
社員教育+契約書チェック
まずは教育です。NISCがいい感じのハンドブックを無料提供しているので、これを読みましょう。お堅い業務文書ではなく、平易な言葉で書かれていてスラスラ読めます。
また、そもそも働く人たちの契約で、秘密を守ることをお願いしているのかが大事です「誰も…消防車を呼んでいないのである！」状態になっていないか再確認しましょう。また、悪意を持って漏洩させたり損害を与えた場合は賠償責任が発生するかも確認しておきましょう。
↑に書いた区分ごとに洗い出した情報資産の、何が秘密情報にあたるのかFAQといて周知しましょう。ソースコードのうち一部だけだったら秘密情報じゃないと思ってました！みたいな誤解が減ると思います。もちろん、自社の情報が漏れるだけでなく、他社の秘密情報を勝手に持ち込まれているケースもあると思うので、そのようなことが発覚したらキチンと削除してもらい記録に残しましょう。
アカウント一覧表を作る
情報の一覧表の次は、アカウントの一覧表です。これは大変だったら四半期に1度くらいでも大丈夫です。Googleのアカウント一覧、Slackのアカウント一覧、GitHubのアカウントを書き出しましょう。すでに委託が終わった人のアカウントを削除していないということはよくあります。それぞれのSaaSでたいていエクスポート機能がついています。それをGoogle SpreadSheetにはりつけて、変更履歴から前回貼り付け時との差分を見ることもできますね。良く忘れがちなのがマーケ系で、Google Analytics / AppStore Connect / Facebookページ管理者などですね。
ここで出てくるのが個人のマシン・Gmailで仕事してもらっている人ですが、可能であればこの仕事専用のフリーGmailを取得していただくか、エイリアス（username+company@gmail.com）を使い、受信トレイでラベル付けして区別しやすいようにお願いしましょう。そうすれば業務終了時にクラウド上のどのデータをクリアすればいいかわかりやすいですしね。また、メールを使わなくてよいのであれば、一定数まで無料でCloud IdentityというGoogle DriveやGCPにアクセスできるアカウントも発行可能です。
結構便利なSaaSを使って事業を進めることが多いのですが、使わなくなったツールが放置されることがあるので、こうした棚卸しはおすすめです。
多要素認証（MFA）をお願いする
2段階認証などともいわれる、アレです。今の時代個人アカウントでも入れていた方が本当にいいので、お願いして回りましょう。最初だけ少し面倒ですが、これがあるだけでリスクを大幅に減らすことができます。
ちなみに、MFAの方法にはSMSなどいろいろありますが、個人的にはGoogle AuthenticatorではなくAuthyを今までおすすめしていました。理由は機種変更が楽だからですが、最近はGoogleのほうも対応したみたいですね。機種変更時にこれ忘れて前の端末捨てると死んじゃうので、MFAの経験が浅い人には合わせて注意喚起しましょう。
ブラウザのプロファイルを分ける
SaaS中心になってくると、業務の半分くらいはブラウザでやる可能性が出てきます。そうなってきたときに強くお勧めしたいのがブラウザのプロファイルわけです。本当はOSのユーザアカウント後と分けた方が安全ではあるのですが、そこまでやると副業系の方は大変なので、せめてブラウザだけ分けてもらいます。
さらにGoogle Workspaceの管理画面では、ほかのGoogleアカウントにログイン禁止を設定することができるので、うっかり別のアカウントとしてGoogle Driveを開いてしまった。別のAWSコンソールで作業してしまった。という事故を減らせます。
この方法だと、ブラウザが自動生成するパスワードを使って、ブラウザに記憶させるという楽ちんなUXでそこそこセキュリティが強化されてしまいます。
ちなみに自分はすでに4プロファイル分けてます。
パスワードやAPIキーを使いまわすときはローテートする
基本的に各種アカウントやAPIキーは人ごとに発行しましょう。ただしお金がない組織では、ときおり1アカウントを使いまわすことがあるでしょう。お金がある組織でもめんどくさいのでAPIキーは共通で配ったりほかの人のデータをコピーして使うこともあると思います。
出来ればやめてほしいですが、せめて3か月とか半年、あるいは主要な業務を担当したメンバーが離れるときはお互いの安心のためにもキーのローテート・パスワード変更するようにしましょう。業務を離れた人が不用意にアクセスできたり、勝手にAPIが叩けたりする可能性があります。
同様に、Google DriveやSlackなど、SaaS間のAPI連携も四半期ごとに見直すと良いでしょう。古くなったサンプルアプリのトークンが残っていたり、本導入に至らなかった検証中で無料利用していて誰も管理していない野良SaaSとつながりっぱなしだったということもあります。
セキュリティソフトは最低限入れて、ドライブ暗号化もできれば
業務がクラウドベースになったとはいえ、マルウエアに感染しないわけではありません。Windowsは標準のWindows Defenderで問題ありません。Macは無料ならAvira、有料ならESETあたりを入れておけばいいんじゃないでしょうか。M1にも対応しているようです。
また、できるだけMacであればFileVault、Windowsであればデバイスのbitlocker暗号化を実施しましょう。カフェでマシンを盗まれても初期化されるだけで済みます。あとあまりにパソコン（OS）が古い方は、会社支給しましょう。おそらく開発環境構築の時点で苦労します。良いスペックのマシンじゃなくてもGitHub Codespacesみたいな環境も使えますしね。
Google Driveなどのバックアップ機能を有効にしよう
ソースコードはGitHubでよい（むしろクラウドストレージにバックアップすると端末が重くなる）のでよいとして、主要なクラウドストレージ（Google Drive/One Drive/iCloud）には、一定の容量のバックアップ機能がついています。
これらはしかも世代バックアップに対応していることも多いので、まだ設定していなければ、デスクトップやドキュメントフォルダを自動バックアップ対象にして、その中にパソコンを初期化しても残ってほしいものを入れておきましょう。ものにもよりますがソースコードを入れると永久にバックアップが終わらない事態になるので注意しましょう。
副業系で会社のアカウントを発行していない方には、フォルダやアカウントを明確に分けたうえでバックアップいただき、業務終了時にはかならずバックアップも含めた削除をお願いしましょう。契約に書かれていることが多くても、フェードアウトしていく場合などで忘れることが多くあります。
スマホで業務ログインする場合
スマホの生体認証をオンにしましょう。Push通知画面には内容をださないようにしましょう。ブラウザのプロファイルは一つしか使えないので、Chrome以外にもWebKitベースの別ブラウザ（Edgeなど）を業務用に入れてログインセッションを分けると便利です。
セキュリティエリアの対策
ここまでが一般エリアで、最悪漏洩してもあきらめるけど、うっかり漏洩や狙われた時の被害を最小化したいための対策です。ここからは個人情報や本番データなど、漏れたり消えちゃったら結構経営がやばいデータの取り扱いです。
権限を分割し人と端末を限定する
まず当たり前のことですが、その情報を読める人、書き込める人を限定することです。かつその権限を持った人は経営上重要なメンバーである（損失が起きたら自分も困る）人に限定しましょう。
Google Driveでは、ファイル単位ではなく機密情報専用の共有ドライブを作成し、限られたメンバーだけアクセス権を付けると良いでしょう。
オフィスがあればそこのIPアドレスからしかアクセスできないようにしてもいいですが、IP制限に対応しているクラウドサービスは少ないです。2段階認証にGoogleのタイタンキーなどFIDOデバイスを有効にするのもいいですね。
また、社員（あるいは正規の会社アカウント）はSSOで固めてしまうと良いでしょう。Azure ADを利用したものや、最近だとCloudFlareが出しているマルチSSOなんかは、複数のドメインに対応できるので、メインメンバーと副業メンバーを同一フローで認証させることができます。逆に言うと、セキュリティ上重要なものは、せめてSSO程度には対応しているSaaSを使いたいですね。
見える化する
たとえば、Google Driveには誰がファイルを開いたかがわかる機能があります。共有ドライブのファイルに開いたログは一定期間管理画面から監査機能を通じてみることができます。
また、ログイン履歴も多くのSaaSで見ることができますので、定期的にチェックしたり、GASを書いてSpreadsheetに書き出したりして、変な時間にログインして変なファイルを見ている人がいないか調べることができます。（上位プランだとログの期間がながくなります）
いったんここまで
コメント欄でこういうのもいるんじゃね？をお願いします。なお、お金がある（かつ専任の情シスがいる）組織は経産省とクラウドネイティブさんがまとめたゼロトラストのやつ読みましょう。