銀行の開発者向けUbuntu [終了]

ユーザーが安全でない可能性のある場所からバイナリをダウンロードすることを望まない銀行やその他の企業向けに、カスタムUbuntuコンピューターを実行する方法（インストールから毎日の使用まで）について文書化されたプロセスと方法はありますか？

apt-get、updateなどは、少数の信頼できるインターネットまたはイントラネットの場所からのみ発生しますか？

更新：最初の回答の後にこれを追加しました。これらのユーザーはサポートであり、システムの初心者ユーザーおよび銀行ソフトウェアの開発者です。そのため、一部のユーザーはsudo権限が必要です。それらを監視する準備ができているので、例外はすぐにキャッチされます（ソースリストの追加など）が、既知のリポジトリからのものをインストールするなどの他のアクションは報告されません。

目的は、セキュリティを確保し、Ubuntuまたはフレーバーを使用して、開発者や他のsudoユーザーができるだけ生産的になることです。（およびWindowsおよびMacコンピューターへの依存を減らします）

.2。また、IT担当者は、sudoユーザーであっても、フォルダーを共有するなどのアクションを実行できないように、ポリシーをユーザーに分割できます。完全なソリューションですか？

これは非常に良い質問ですが、答えは非常に難しいです。

まず、@ Timothy Truckleを開始するための良い出発点があります。セキュリティチームがすべてのパッケージを検証できる独自のaptリポジトリを実行します。しかし、それはほんの始まりに過ぎません。

次に、グループを実装します。ユーザーがサポートから多くの助けなしで必要なことを行えるようにすることを目指します。しかし、銀行業務では、物事を本当にロックダウンする必要があります。実際、多くの企業構造では、物事をロックダウンしたいと考えています。したがって、通常のユーザーにあらゆるレベルでsudo特権を付与することはおそらく不可能です。

特定のグループがジョブを実行するために昇格されたアクセス許可を必要としないように、おそらくあなたがすることは何かを設定することです。

繰り返しますが、ほとんどの企業環境では、ソフトウェアのインストールは解雇される可能性があります。あなたがソフトウェアを必要とするなら、あなたはITに電話して、彼らはあなたのためにそれをします、または要求チェーンまたはそのようなものがあります。

理想的には、通常の従業員が何かをインストールしたり、昇格した権限を必要としたりすることはありません。

開発者にとっての質問は少し異なります。おそらくインストールする必要があり、sudoが必要かもしれません。しかし、それらのボックスは「危険ネットワーク」上にあり、重要なシステムに直接接続することはできません。

IT /サポートスタッフにはsudoが必要です。ただし、コマンド、プロセス（ペーパーワーク）、またはその他の方法でsudoアクセスを制限できます。「2つの目をした校長」のようなものとそれを実装する方法についての全巻があります。ただし、監査ログが存在し、ほとんどのニーズを満たすように構成できます。

それでは、質問に戻りましょう。Timothy Truckleの答えは100％正しいですが、あなたの質問の前提は外れています。Linux OSを保護することは、特定のユースケースに必要な設定を選択することよりも重要であり、物事を保護する方法についての一般的なアイデアについてではありません。

イントラネット内に独自のdebianリポジトリプロキシをセットアップします。

debianリポジトリプロキシがの唯一のエントリになるように、ubuntuインストールをカスタマイズします/etc/apt/sources.list。

出来上がり：クライアントにインストールされているソフトウェアを完全に制御できます（スーパーユーザー権限を持っているユーザーがいない場合）。

更新：最初の回答の後にこれを追加しました。これらのユーザーはサポートであり、システムの初心者ユーザーおよび銀行ソフトウェアの開発者です。そのため、一部のユーザーはsudo権限が必要です。それらを監視する準備ができているので、例外はすぐにキャッチされます（ソースリストの追加など）が、既知のリポジトリからのものをインストールするなどの他のアクションは報告されません。

カスタムインストールでは、/etc/sudoersファイルを変更して、ユーザーの実行sudo apt updateを許可し、でsudo apt install始まる他のコマンドは許可しないようにすることができますapt。もちろん、制限sudo bash（または他のシェル）も必要です。

これまで見てきたほぼすべてのショップで、開発者は開発マシンに完全にアクセスできましたが、これらのマシンはインターネットとソースコードリポジトリにしかアクセスできませんでした。

ソースコードはチェックインされ、信頼されたマシン（通常、開発者は管理者権限を持っていないか、管理者権限を必要としません）でコンパイルされ、そこから内部ネットワークにアクセスするテストシステムにデプロイされます。

これらのマシンを開発者が使用するか、別のテストチームが使用するかは組織次第ですが、通常、信頼できるマシンと信頼できないマシンの境界は別々のマシン間であり、それらの間のインターフェイスは検証可能です（ソースコードのコミットなど）。

フロントデスクの従業員は、管理者権限を一切取得しません。これらのすべてのマシンにソリティアを展開すると、このポリシーに関する苦情はほとんどなくなりました。