前提
ソフトウェア開発環境がインターネットと隔離されていることは、昨今のセキュリティ事情からよくあることと思います*1。
ソフトウェアエンジニアの場合、事務作業で使うPC環境とは別にソフトウェア開発用のPC環境があり、それは事務作業で使うネットワーク環境とは異なるソフトウェア開発のネットワーク環境につながっており、インターネットとはつながらない（あるいは強度な制約のもとインターネットにつながる）環境となります。
例えば、事務作業用のPCと開発用のPCが物理的に分かれていて、それぞれ別々なネットワークに接続されていることや、事務作業用PCの利用は仮想マシンを通して行い、開発用PCと仮想マシン間のデータ交換は不可となっていることなどです。
開発したソフトウェアを組み込む製品と開発環境をつないで、ソフトウェアのインストール・更新、ログの取得、デバッグ、各種設定をする際は、製品が開発用ネットワークとはつながっていないため、開発用PCを開発用ネットワークから切り離して使うこともあります。場合によっては開発用ネットワークなしに単独で最初から最後まで開発を行うこともあります。
このように開発環境がインターネットとは接続されていない場合は、開発に使うツールの選定時点からそのことを考慮に入れておくことが不可欠です。
開発環境で使うツールの準備
インターネットと隔離されているので、開発環境で使うツールは開発環境用のネットワークの中で展開できるようにする必要があります。
ここで困るのが、Webインストーラーのみ提供され、インターネットとつながっていないとインストールができないツールです*2。
開発用PCをインターネットにつないでインストールしてから開発環境用ネットワークに持ち込めばいいのでは？との声があるかもしれませんが、開発データを抱えたPCをインターネットに接続することは原則不可でしょう。
インストールはできるもののライセンス認証にインターネット接続が必須となるツールも使うことができません。
ツール本体はオフラインでインストールできても、プラグインの追加がインターネット接続必須となると困ります。
インストールができたとしても、実行時に問題があるというケースも困ります*3。
主要なJava開発ツール（統合開発環境）のNetBeans、Eclipse、IntelliJ IDEAは、いずれもインストールイメージをオフラインで展開して使用できます。
ビルドツール
maven、gradleはJavaのビルドツールとして非常に流行っておりますが、インターネットに接続していることをほぼ前提としているツールなので、インターネットと隔離した開発環境での使用には不適です。
mavenは、自身の実行にもインターネットからモジュールのダウンロードが発生します。オフラインオプションもありますが、一度オンラインでダウンロードしたキャッシュを使うものなので、ゼロから使うには、mavenセントラルリポジトリのクローンをNexusやArtifactoryなどで開発ネットワーク内に構築し、各開発PCからはそのクローンを参照する必要があります*4。ただし、開発環境から切り離しての作業には制限があります*5。
gradleは、mavenに比べるとオフライン使用がまだ容易ですが、オフラインで使用できるようにするための手間はやはり発生します。以前、Android Studioで開発した際は、SDKのインストール場所、ライブラリの配置などを調整する必要がありました。その時の取り組みは次のブログに記載しています。
現時点では、引き続きAntを使うのがインターネット隔離環境では適すると言えます。
バージョン管理ツール
開発用PCが開発ネットワークに接続して使用、あるいは切り離して使用するので、リポジトリサーバーへの常時接続がなくても管理できる分散リポジトリ方式のGitやMercurialがよいでしょう。特に製品組み込み後にその場で修正をした場合は、開発ネットワークから切り離されている間にリポジトリへのコミットを重ねておき、もどってから中央リポジトリに反映することができるのは大きな利点です。
CIツール
計画的な（デイリーの）ビルド・成果物作成はJenkinsなどのサーバーを使いますが、製品と隣り合わせでビルド・インストールを繰り返すときには持ち出しできる（開発PCに一緒に乗せて使える）CIツールがあるといいですね。これは今後調査していきたいと思っています。
不具合管理・プロジェクト管理ツール
プロジェクトの不具合状況、進捗状況は、ソフトウェア開発メンバーだけでなく、組織の管理者層や品質保証部門からも参照したい情報です。ソフトウェア開発環境の中に閉じたツールを立てると、開発メンバーしか共有できません。
隔離したネットワークの双方から参照したい場合の実現方法は今後調査していきたいと思っています。
コミュニケーションツール
開発環境とは別に、事務作業用の環境で使うか、開発環境の中に独自にツールを用意するかの選択（あるいは併用）となります。
ビルド結果の通知、プロジェクト管理ツールからの通知などをコミュニケーションツールで受けるので開発環境の中に置きたいところですが、開発以外のメンバーとのコミュニケーションには事務作業用の環境で使えるツールが必要です。インターネット接続環境ではチャットツールの活用でコミュニケーションが良好になっています。隔離したネットワーク内およびその外側とでコミュニケーションをとる方法を今後調査したいところです。
現状と今後
前提で書いた開発環境は、かなり制約がつよい（利便性が犠牲になっている）環境となっています。プログラマー視点で普段目にする技術情報では、便利な技術の紹介がほとんどで、インターネット上のサービスをガンガン使うものばかりですが、所属する会社組織において要求されるセキュリティレベルによってはそうした便利技術が使えないということが私の経験では多いです。
前提のような環境を強いられなくてもセキュリティが保てるような開発環境をどうしたら構築できるかについて、少しずつ検討していきたいと考えています。
インターネット接続できない場所が意外と
先日出張の際、建物の中のある会議室では携帯キャリアによってつながる/つながらないが分かれました。
また、出張の合間に車で移動する際、キャリアすべてがつながらない場所が少なからずありました。
*1:開発用PCがインターネットとつながってメールやWebができると、開発環境にある情報が漏洩するリスクがあり、入口対策でファイアウォールやウィルス対策をしていても、標的型攻撃や開発ツール・ライブラリ等に仕込まれたサプライチェーン攻撃等による漏洩は防げません。開発環境に攻撃が及んでも社外に漏洩しないよう隔離をして対策を取るケースです。
*2:Visual Studio 2017以降はISOイメージが提供されなくなり、オフラインインストールが困難になりました。インターネットに接続したPCでいったんWebインストーラーを動かしオフラインイメージをダウンロード、それを検疫等必要な処置をして開発環境へ持ち込み、開発PCへインストールする手順は用意されていますが、コード署名の証明書が追加で必要なるとか、ダウンロードしたPCと構成が違うときにエラーになるといったトラブルが生じることがあります。また、インターネットに接続するPCでWebインストーラーを実行できるかは組織のセキュリティポリシーにより許されないこともあります。
*3:過去にあったのが、アセンブリ（DLLファイル）にコード署名が施されており、ツールを起動するたびにコード署名の検証をするがその際インターネット接続を試み、タイムアウトが発生してから起動するというもの。ツールの起動に数分待たされてしまいました。
*4:すごい大変
*5:キャッシュしたコマンドは実行可能だが、切り離してから始めて使うコマンドはキャッシュがないのでエラーになってしまう
