-
タグ
タグ
- セキュリティ
- 人材開発・教育
- システム開発
- アプリ開発
- モバイルアプリ
- DX
- AI
- サイバー攻撃
- サイバー犯罪
- 標的型攻撃
- 脆弱性
- 働き方改革
- 企業市民活動
- 攻撃者グループ
- JSOC
- JSOC INSIGHT
- サイバー救急センター
- サイバー救急センターレポート
- LAC Security Insight
- セキュリティ診断レポート
- サイバー・グリッド・ジャパン
- CYBER GRID JOURNAL
- CYBER GRID VIEW
- ラックセキュリティアカデミー
- すごうで
- ランサムウェア
- ゼロトラスト
- ASM
- EDR
- SASE
- デジタルアイデンティティ
- インシデントレスポンス
- 情シス向け
- 対談
- CIS Controls
- Tech Crawling
- クラウド
- クラウドインテグレーション
- データベース
- アジャイル開発
- DevSecOps
- OWASP
- CTF
- FalconNest
- セキュリティ診断
- IoT
- EC
- サプライチェーンリスク
- スレットインテリジェンス
- テレワーク
- リモートデスクトップ
- アーキテクト
- プラス・セキュリティ人材
- 障がい者採用
- 官民学・業界連携
- カスタマーストーリー
- 白浜シンポジウム
- CODE BLUE
- 情報モラル
- クラブ活動
- 初心者向け
- 趣味
- カルチャー
- 子育て、生活
- 広報・マーケティング
- コーポレート
- ライター紹介
- IR
アジャイル開発センターの大沼です。
先日、「GitHub Enterprise Summit」という、リモート開発における生産性の向上をテーマにしたカンファレンスで講演をしました。様々な企業のシステム開発を担うセキュリティに強いシステムインテグレータとしての立場で、GitHub Enterprise Cloud導入に向けた検討ポイントについてお話ししたので、記事でもご紹介したいと思います。
GitHub Enterprise Cloud導入の背景
まず、ラックがクラウド上でSaaSとして提供されるGitHub Enterprise Cloudの導入を考えた2つの背景についてご説明します。
1つ目はリモートワークで発生する課題解決です。もともと当社の開発環境はファイアウォールで守られ、セキュリティ監視のある堅牢な社内ネットワークの中で管理していました。在宅での開発やサテライトオフィスでのリモートワークが進みだした頃、VPN接続を使って社内ネットワークに接続するようになっていきました。そうした状況では、「今日だけは在宅」「短時間だけサテライトオフィス」という使い方を想定していたのです。
ところが、昨年のコロナ禍で在宅勤務が基本になりました。すると一気にVPN接続の数が増え、帯域が逼迫し、ネットワークが不安定な状況に陥ってしまいました。現在は大幅に改善されましたが、まだ若干のストレスを感じる状態が続いています。
さらに在宅勤務がメインとなると、会社に誰もいない状況が生まれます。開発環境がダウンしたときに対応する人がおらず、誰かが出社して対応する場合もあります。出社していれば10分か15分で終わるはずの対応に半日以上かかることもありました。
2つ目は作業効率化のためです。ラックでは開発プロジェクトごとに、それぞれ別々の開発環境を構築するのが一般的です。各プロジェクトで最適な構成になるように環境構築していますが、共通化できそうな構築作業をプロジェクトごとに行っていました。そうではなく、共通する作業はまとめて行った方が効率的です。
リモートワークで発生する課題、各プロジェクトで行われている無駄な作業コストの課題を、GitHub Enterprise Cloudを導入することで解決したいと考えました。
GitHub Enterprise Cloudを導入してみよう
GitHub Enterprise CloudではOrganizationという単位でリポジトリが管理されます。では、Organizationを実際の組織にどのように割り当てればよいでしょうか。
我々は様々なお客様のシステムを扱うシステムインテグレータのため、組織(部署)の中には数多くのプロジェクトが存在します。もちろん、お互いのプロジェクトの開発環境は参照できないようにする必要があります。組織(部署)という単位でOrganizationを割り当てた場合、リポジトリ単位でさらに細かく権限を設定しなければならなくなり、設定ミスなどのリスクが発生します。
そこで、関係ないプロジェクトからの参照、組織外からの参照を防ぐため、プロジェクト単位でOrganizationを割り当てることにしました。
上記の前提に従い、今回、主にセキュリティ面に配慮して重点的に検討しているポイントを5つご紹介します。
5つの検討ポイント
1.リポジトリの公開・複製
意図的にせよ、操作ミスにせよ、Enterprise内のリポジトリをパブリックな状態で作ってしまうことで、外部からのアクセスが可能になるリスクが想定されます。また、GitHubにはリポジトリを簡単に複製できる機能があります。Enterprise内のリポジトリをEnterprise外に複製されると、統制が効かなくなり組織外の人から参照できてしまうおそれがあります。
これらを抑制するために、3つの施策を検討しています。
- 操作ミスなどによる意図しない公開・複製を起こさせないための検討
これは、GitHubが持っている公開・複製の禁止といったシステム的な制御を考えています。 - リポジトリをローカルに持ってきた人が自分のリポジトリにアップロードする場合の検討
悪意がある場合はしかるべき対処をするしかありませんが、悪意がなく実施してしまう場合も考えられます。そのため、運用ルールの整備と教育が必要となってきます。GitHubの仕組みと操作により発生する漏えいなどのセキュリティリスクをしっかりと教育していくことが大切です。 - 何らかの理由でリポジトリに公開されてしまった場合の検討
公開状況を点検する運用を考えなくてはいけません。例えばGitHubの検索機能によって、定期的に検索することで、早急に誤って公開されたリポジトリを発見するようなことを考えています。
2.Organizationの公開
リポジトリは非公開の状態で作ることができますが、Organizationにはそうした設定がありません。リポジトリが見えなくても、OrganizationのURL自体はアクセス可能です。中身が見えないので問題ないように思えますが、URLから悪意ある攻撃者に不要な情報を与えてしまうリスクがあります。例えばOrganizationの名称に顧客名が使われることや、プロジェクト名から何かしらの情報を不用意に与えてしまう可能性です。
対応策として、Organizationの命名規則ガイドラインを作り、その上で管理者がOrganizationを作るようにします。さらにOrganizationの点検をします。GitHub Enterprise Cloudの中に所属するOrganizationの中に命名規則に従わない名前が無いか確認する運用を考えています。
3.GitHubユーザーアカウント
GitHub Enterprise CloudのアカウントはGitHubの個人アカウントを招待する仕組みになっています。必然的に仕事のアカウント、プライベートのアカウントが混在します。GitHubの公式ドキュメントにも、1つのアカウントで仕事もプライベートも対応することを推奨します、と書かれています※が、やはりお客様のシステムを扱うシステムインテグレータという立場だと仕事とプライベートのアカウントを切り分けて管理したいというのが本音です。
※ 「個人での使用や仕事での使用など、1つのアカウントを複数の目的で使用できます。複数のアカウントを作成することはおすすめしません。」
GitHub アカウントの種類 - GitHub Docs
そこで、まずは既存の個人アカウントを招待するにあたり、既存のアカウントを招待すべきか否かの判断基準を設けることを検討しています。次に新規のアカウントを作成する場合の作成手順、アカウントの設定内容についてのガイドラインを用意し、ガイドラインに沿ってアカウントが設定されているか点検しましょうという議論をしています。
4.認証
アカウントを使っているのは、本当に社員本人であるのかという問題があります。これに対して、認証の強化と監査ログでユーザーのアクションを点検するという2点を検討しています。どちらもGitHub Enterprise Cloudの機能として提供されています。認証の強化に関しては、2要素認証を強制することによって、本人確認を強化します。さらにSAML認証の機能を使うことで、このGitHub Enterprise Cloudへのアクセス時に社員だという事をしっかり確認します。監査ログに関しては、監査ログの画面やAPIが充実しているので、どのように点検をして行くかこれから考えていくところです。
5.プロジェクト活用
GitHub Enterprise Cloudのライセンス購入をした後、各プロジェクトでGitHub Enterprise Cloudの採用が進まない、採用されても活用されない状況は避けたいという内容です。使い方がわからない、何をしていいかわからない、ということはもちろん解決すべきですが、使ってみたのに今までより開発のスピードが落ちたということがあっては、導入の意図と反します。
そこで、GitHub Enterprise Cloudの採用を推進し効果的に活用するため、社内説明会や利用支援トレーニングを検討しています。まず社内説明会で使い方を共有し、運用方法や利用のメリットを伝えます。安全に運用できるのかといった不安もここで解消します。また、継続的に支援をする体制を作る必要もあると考えます。さらに、GitHubの使い方やGitHub Actionsの活用方法、Gitそのものの使い方など、GitHub活用のためのトレーニングも考えています。
以上が、GitHub Enterprise Cloudを導入する際に、セキュリティ面で重点的に検討している5点のご紹介でした。
おわりに
GitHub Enterprise Cloudの利用についての懸念は、機能による制約だけで解消できるわけではありません。運用方法の検討、社内へ向けた説明、利用にあたってのトレーニングまで検討した上で、最終的に社内利用者がメリットを感じる、効果のある導入としたいと考えています。GitHub Enterprise Cloudの導入を同じように検討している皆さまにとってお役に立つ情報であったならば、幸いです。
なお、今回GitHub Enterprise Cloudを導入するにあたって、上記のようにセキュリティについて検討する過程をご紹介しました。他のクラウド環境を使用する際にも同様に、十分なセキュリティ対策を検討していく必要があります。
ラックではクラウド環境での開発について、セキュリティ面の検討だけでなく、実際の運用のお手伝いもしています。システム開発の各工程におけるセキュリティ診断・実装を行う「システムセキュリティデザイン」サービスの他、HashiCorp社のTerraform、パロアルトネットワークス社のPrisma® Cloud、Elastic社のElastic Stackなどの製品を用いて、企業がクラウド環境に統制を効かせて安全に活用するためのサービスを展開しております。
クラウド環境における開発、運用について、お悩みのことがあれば、ぜひご相談ください。
タグ
- セキュリティ
- 人材開発・教育
- システム開発
- アプリ開発
- モバイルアプリ
- DX
- AI
- サイバー攻撃
- サイバー犯罪
- 標的型攻撃
- 脆弱性
- 働き方改革
- 企業市民活動
- 攻撃者グループ
- JSOC
- もっと見る +
- JSOC INSIGHT
- サイバー救急センター
- サイバー救急センターレポート
- LAC Security Insight
- セキュリティ診断レポート
- サイバー・グリッド・ジャパン
- CYBER GRID JOURNAL
- CYBER GRID VIEW
- ラックセキュリティアカデミー
- すごうで
- ランサムウェア
- ゼロトラスト
- ASM
- EDR
- SASE
- デジタルアイデンティティ
- インシデントレスポンス
- 情シス向け
- 対談
- CIS Controls
- Tech Crawling
- クラウド
- クラウドインテグレーション
- データベース
- アジャイル開発
- DevSecOps
- OWASP
- CTF
- FalconNest
- セキュリティ診断
- IoT
- EC
- サプライチェーンリスク
- スレットインテリジェンス
- テレワーク
- リモートデスクトップ
- アーキテクト
- プラス・セキュリティ人材
- 障がい者採用
- 官民学・業界連携
- カスタマーストーリー
- 白浜シンポジウム
- CODE BLUE
- 情報モラル
- クラブ活動
- 初心者向け
- 趣味
- カルチャー
- 子育て、生活
- 広報・マーケティング
- コーポレート
- ライター紹介
- IR