4

私は機密データを処理および保存するアプリケーションを構築する場所で働いています。3つの環境があります。開発、UAT / QA（ユーザーアクセプタントテスト）および本番

私の職場の開発者は、UATまたはProductionにアクセスできず、Devへのアクセスが制限されています。devでできることは、devDBサーバーに接続することだけです。開発サーバー自体にアクセスすることはできません。そのため、開発者のWebサーバー（iis）などで遊ぶことは許可されていません。変更が必要な場合は、ネットワーク管理者に作業要求を送信する正式なプロセスを実行する必要があります（完了するまでに数日かかる場合があります）。開発者がUATまたはPRodデータベースでチェックするものを要求した場合も同様です。この厳格なアクセス制限は、アプリケーションをサポートしようとするときに本当にイライラします。

物事が台無しになるリスクを減らすので、なぜこれらのポリシーがあるのか​​理解できます。しかし、これは問題の解決に本当に時間がかかり、苦痛になります。修正に5分かかる可能性のあるもの（開発者がアクセスできる場合）は、解決に数日かかる可能性があります。

この種の厳密なアクセス権は正常ですか？

4

7 に答える 7

3

それが正常であるかどうかを言うのは難しい。たとえば、私は投資銀行で働いてきました。投資銀行では、あなたが説明する手順よりもさらに厳格な手順があります。私はまた、手順がまったくない1つのIBで働いてきました。しかし、前者はまだ営業しているのに対し、後者は最近有名に破産したことは注目に値します！

于 2009-07-17T08:34:51.000 に答える
3

開発者がアクセスできない場合、これは「開発サーバー」ではありません。今では、実稼働、実稼働前、テスト、開発の4つの環境があることは前代未聞ではありません。（開発者のアクセスを増やすことでソート）。名前を無視すると、開発サーバーがないことを除いて、同じ構造になっているようです。

于 2009-07-17T08:58:04.807 に答える
2

私には少しきついですね。通常、私はDevサーバーを完全に制御できることを期待します。テストサーバーで読み取り専用アクセスを確認できれば幸いです。正直なところ、本番サーバーを（開発の観点から）見ることには興味がありません。

もちろん、ここでは次のような仮定がなされています。

  • 3つの環境はまったく同じように始まりました
  • prodに加えられた変更は、テストを介してdevにカスケードされます。
  • Devでの構成の変更は、デプロイヤーがテストおよび本番環境で行います。

ここでの手順では、開発者がテストにデプロイすることを許可していません。これは、prodにデプロイするサードパーティに引き渡す前のテスター次第です。

これにより、リリース手順が他の何よりも検証されます。

それで; すべてのチオングがリリースについて文書化されている限り、開発以外のものにアクセスする必要はありませんが、開発環境を適切なレベルで制御できると便利です。

于 2009-07-17T08:42:00.750 に答える
2

それはあなたが欲しいものの問題です

作業には2つの競合する要件があります。

  • 問題の修正/新しいコードの開発のための迅速なターンアラウンド。
  • 機密データが漏洩しないようにする。

あなたの会社は、問題を修正して新しいコードを迅速に開発する能力を持つよりも、機密データが漏洩するリスクを減らす方が良いと（意識的または無意識に）決定しました。私の会社は同じ方向に傾いていますが、あなたが説明している極端なところにそれを持っていくのに十分な手がかりはありません。

これはビジネス上の決定です。

これは、（おそらく無意識のうちに）あなたの会社が上向きのリスク（ソフトウェアを機能させる）よりも下向きのリスク（データの漏洩）に高い価値を置いているために作られています。これは一般的なバイアスです-リスク回避的であると知られています（それよりも良い用語があると確信しています-誰か？）、そしてそれは私たちの仕事を成し遂げようとして克服しなければならない私たちにとって非常に迷惑ですそれらの障害の影響をよく理解していない人々によってそこに置かれたたくさんの障害。

要約すると

  • これはビジネス上の決定です。
  • それは、さまざまなリスクがどのように認識されているかという問題です。
  • それはリスク回避的な立場を反映しています。
  • このポジションは、おそらく会社が完全に無意識のうちに到達したものです。
于 2009-07-17T09:13:24.057 に答える
1

変更管理についてです。システムへのすべての変更が追跡され、リリースノートに反映されていること、およびシステムのある部分での変更が別の部分で問題を引き起こさないことを確認します。

私の責任であれば、各開発者に、実稼働環境をエミュレートするために必要な数の仮想マシンを実行し、それらのマシンを完全に制御できる強力なPCを提供します。そして、完全なリリースノートを作成できるように、公式の開発環境へのすべての変更が文書化されていることを確認してください。

于 2009-07-17T11:05:13.520 に答える
0

小さな会社でも、エンジニアはコード以外の開発環境にあまりアクセスする必要はありません。コア環境はかなり静的なままである必要があります。Webサーバー上のどのような種類のものを急速に変更したいですか？

于 2009-07-17T09:19:17.120 に答える
0

Stackifyをチェックしてください。開発者がアプリケーションと本番サーバーをより可視化できる新しいサービスをリリースしました。ログファイル、構成ファイル、Windowsイベントビューアなどへの簡単な読み取り専用アクセスを提供できます。説明した問題を解決できます。基本的に、DevOpsサポートを発明しました：http：//www.stackify.com

于 2012-08-30T01:24:11.183 に答える