web-dev-qa-db-ja.com

プロダクションPython環境を安全に保つにはどうすればよいですか？

私の仕事のほとんどは、Django（a Python web framework））でウェブサイトを作成し、自分のサーバーまたはクライアントのサーバーに展開することです。私はvirtualenvを使用して、サイトをシステムパッケージから分離し、おそらくそこに60〜80個のパッケージをインストールして、そのロットを20を超えるサイト間で共有します。

このアプローチに対するこの明らかな制限は、使用するパッケージをアップグレードする場合、すべてのサイトをテストする必要があることです。私は、かなりの数の個別のvirtualenvを維持する必要がないという公平なトレードオフを考えています。

そして、それは本質的に私の全体の問題です。 いったいどのようにvirtualenvの展開を維持しているのでしょうか？人々は単にそれらをゴミ捨て場のように扱っているようですが、プログラミングユニバースがこの1週間で何かを学んだ場合= Ruby on Rails爆発、古いバージョンのソフトウェアの使用は受け入れられません。

最新のpipを使用して現在のパッケージバージョンを確認する単純なスクリプトがありますが、正確ではありません。また、セキュリティのアップグレードと機能のアップグレード（何日もテストと修正が必要）を区別しません。

もっと良いものを探しています。 Djangoの新しいセキュリティリリースがリリースされた場合、またはサポートが終了した場合に通知することができるものを探しています。私を助けるための何かが必要です（および他のPython devops）スキャナーとスクリプトで子供たちの波が私たちのサーバーをボットネットに変換した後に泣く人々の次のバッチにはなりません。

そのようなものは存在しますか？

web-developmentpythonsecuritymaintenance
7
Oli

主要なGNU/Linuxディストリビューションには、ディストリビューション内のすべてのパッケージを安全に保つ責任がある専門のセキュリティチームがあります。これらのチームと調和するのに十分なリソースを費やすだけの余裕がない場合、（最高のセキュリティが目標である場合）最善の解決策は、彼らの作業に依存し、ディストリビューションのパッケージを使用することです。段階的なリリース（ Debian など）を含むディストリビューションは、依存関係が壊れないように、パッケージにパッチを適用しようとします。

もちろん、ディストリビューションのパッケージを使用すると、Python仮想環境の柔軟性が失われます。したがって、これは別のトレードオフの三角形のようです：高セキュリティ、低コスト、インストールの柔軟性。2つ選択してください。 。

Distribution packages vs. virtual environment

2
SergiyKolesnikov

buildout を使用して、再現可能で分離されたデプロイメントを作成します。

ビルドアウトはvirtualenvのように機能し、卵をインストールして、それらをPythonインストールから分離した状態に保ちます。また、使用するバージョンを制御できるという点でpipのように機能します。 。ただし、buildoutはビルドツールでもあり、アプリケーションやテストに合わせて、必要に応じて任意のパーツをビルドできるレシピを備えています。

私の仮想環境には、新しいプロジェクトの新しいブートストラップを作成するためのzc.buildout Egg以外のものが含まれていません。

私が構築する典型的なビルドアウトには、開発、継続的インテグレーション、本番環境に適合するようにいくつかの構成ファイルがありますが、base.cfgは常に次のようになります。

[buildout]
extends = 
     versions.cfg

newest = false

eggs = customer_project_name

[Django-base]
recipe = djangorecipe
settings = settings
eggs = ${buildout:eggs}
project = customer_project_name
projectegg = ${:project}

[python]
recipe = zc.recipe.Egg
interpreter = python
eggs = ${buildout:eggs}
initialization =
   import os
   os.environ['Django_SETTINGS_MODULE'] = '${Django:projectegg}.settings'

versions.cfgを使用して、すべてのバージョンを固定し、偶発的なアップグレードを防ぎます。

versions.cfgファイルを使用しているため、すべてのバージョンファイルを解析して、影響を受けるプロジェクトを確認するのは簡単です（結局のところ、これはConfigParserファイルにすぎません）。パッケージのアップグレードは問題です。それらのピンを更新し、プロジェクトを再テストします。

テストが完了したら、更新されたバージョンの更新をお客様のサーバーにプッシュし、ビルドアウトを再実行します。

顧客向けのアップグレードウィンドウを計画、テスト、および検索する必要があるため、セキュリティ修正のアップグレードはいずれにしても専用のメンテナンスタスクであることに注意してください。

1
Martijn Pieters

Dockerを使用することをお勧めします。Dockerは基本的なセキュリティ構造を提供し、自動的に更新され、完全に移植可能です。 Djangoサイトのデプロイは完全に苦痛ですが、Dockerを使用しているため、開発環境と本番環境はほとんど同じなので、プッシュとプルのみ=）

トピックに関するいくつかの良い読み：

http://pawamoy.github.io/2018/02/01/docker-compose-Django-postgres-nginx.html

https://wsvincent.com/Django-docker-postgresql/

1
nyx00

requires.io の features をご覧ください。これはあなたが探しているもののようです。

BitbucketまたはGitHub-Accountは無料です。

それとは別に：

私は、公共部門の機密データを扱う必要がある状況で働いています。また、導入プラットフォームとしてCentOSを使用しています。ほとんどの場合、CentOSに付属する.rpmpackagesのセキュリティアップデートに依存しています。また、場合によっては、選択した必要な「python-packages」を独自にパッケージ化することもあります。当社のインフラストラクチャチームは、セルフパッケージされたものの既知のセキュリティ問題を追跡し、再パッケージを行います。これが私たちにとってどのように機能するかです。

PS：コンテナ側にいる場合は、コンテナイメージのスキャンと同様のサービスを提供する anchore があります。 。

0
Thomas Junk

エクスプロイトが存在する場合に通知を受け取るために、エクスプロイトについて通知するRSSフィード、サービス、および製品があります。少なくとも、管理者はおそらくCVEまたはNVD（CVEを含む）に従う必要があります。

Virtualenvではなく、アプリケーションで使用されるライブラリのエクスプロイトを管理する方法は？たとえば、ImageMagick、python実行可能ファイル自体、またはpythonが使用するシステムライブラリ。プラットフォームをアップグレードして、必要なvirtualenvとアプリケーションの検証。

私の仕事では、Pythonを含む独自のパッケージ（RPM）を作成します。システムライブラリのセキュリティ上の欠陥（プラットフォームのアップグレード、アプリケーションの検証）がある場合、私たちは同じ問題に直面しています。ただし、アプリケーションライブラリまたはpython自体は、ツールチェーンパッケージ内にあるため、簡単に管理できます。それを修正し、継続的インテグレーションビルドを通じて実行します。これにより、すべてのプロジェクトが再ビルドされ、新しいパッケージがすべて生成されます。ツールチェーンをアップグレードします。

pythonまたはDjango私が知っている）に固有の垂直統合ソリューションはありません。

0
dietbuddha