銀行の開発者向け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リポジトリプロキシ をセットアップします。
buntuインストールのカスタマイズ ので、debianリポジトリプロキシが/etc/apt/sources.listの唯一のエントリになります。
出来上がり：クライアントにインストールされているソフトウェアを完全に制御できます（スーパーユーザー権限を持っているユーザーがいない場合）。
更新：最初の回答の後にこれを追加しました。これらのユーザーはサポートであり、システムの初心者ユーザーおよび銀行ソフトウェアの開発者です。そのため、一部のユーザーはSudo特権が必要です。それらを監視する準備ができているので、例外はすぐにキャッチされます（ソースリストの追加など）が、既知のリポジトリからのものをインストールするなどの他のアクションは報告されません。
カスタムインストールでは、/etc/sudoersファイルを変更して、ユーザーがSudo apt updateおよびSudo apt installを実行できるようにしますが、aptで始まる他のコマンドは実行できません。もちろん、Sudo bash（またはその他のシェル）も制限する必要があります。
これまで見てきたほぼすべてのショップで、開発者は開発マシンに完全にアクセスできましたが、これらのマシンはインターネットとソースコードリポジトリにしかアクセスできませんでした。
ソースコードはチェックインされ、信頼されたマシン（通常、開発者は管理者権限を持っていないか、管理者権限を必要としません）でコンパイルされ、そこから内部ネットワークにアクセスするテストシステムにデプロイされます。
これらのマシンを開発者が使用するか、別のテストチームが使用するかは組織次第ですが、通常、信頼できるマシンと信頼できないマシンの境界は別々のマシン間であり、それらの間のインターフェイスは検証可能です（ソースコードのコミットなど）。
フロントデスクの従業員は、管理者権限を一切取得しません。これらのすべてのマシンにソリティアを展開すると、このポリシーに関する苦情はほとんどなくなりました。