タグ付けされた質問 「best-practices」

私たちのオフィスには、純粋に内部DNSがセットアップされたローカルエリアネットワークがあり、その上にすべてのクライアントがという名前が付けられていwhatever.lanます。VMware環境もあり、仮想マシンのみのネットワークでは、仮想マシンに名前を付けますwhatever.vm。 現在、仮想マシンのこのネットワークは、私たちのローカルエリアネットワークから到達可能ではないですが、私たちは、これらの仮想マシンに、移行する生産ネットワークを設定しているだろう LANから到達可能であるが。その結果、我々は、我々が設定しているこの新しいネットワーク上のゲストに適用ドメインサフィックス/ TLDのための規則に落ち着くしようとしているが、我々は良いものを考え出すことができない、という与えられた.vm、.localと.lan私たちの環境にはすべて既存の意味合いがあります。 それでは、この状況でのベストプラクティスは何ですか？純粋に内部ネットワークに安全に使用できるTLDまたはドメイン名のリストはありますか？

115 domain-name-system  local-area-network  hostname  best-practices 

私はこれについて上司と議論しました。一見、ラップトップの前のユーザーは自分のドキュメントフォルダーでしか動作しませんでしたが、次のユーザーに常に新しいOSをインストールする必要がありますか、それとも古いプロファイルを十分に削除する必要がありますか？インストールされているソフトウェアは、ほとんどの場合、次のユーザーにも必要です。 インストールが必要だと思いますが、ウイルスと個人データに関する私自身の主張を除いて、そうする理由は何ですか？ 当社では、PCをプライベートメールなどに使用することが許可されています。一部のPCにはゲームがインストールされています。私たちにはちょっとしたモバイルユーザーがいますが、それはしばしば顧客のサイトにいるので、私は彼らを非難しません。 また、そのため、多くのローカル管理者がいます。 私は個人使用とローカル管理者アカウントの利用可能性の両方が良いアイデアではないことを知っていますが、それは私がここで働く前にそれがどのように扱われたか、そして私は訓練生を終えた後にのみこれを変更できます;） 編集：投稿された回答はすべて関連があると思います。また、私たちの会社で行っているいくつかの慣行は、最初から始めるのが最善ではないことも知っています（たとえば、多すぎる人のローカル管理;）。 今のところ、議論に最も役立つ答えはRyderからのものだと思います。彼が答えで与えた例は誇張されているかもしれませんが、以前の従業員が個人データを忘れる前に起こりました。私は最近、古いラップトップでゲームRunawayの小売コピーを見つけましたが、プライベートイメージが残っているケースもいくつかありました。

112 windows  installation  best-practices  operating-system 

これは奇妙な質問のように聞こえるかもしれませんが、同僚の何人かと活発な議論を生み出しています。8個または12個のディスクのようなもので構成される、中程度のサイズのRAIDアレイを検討してください。ディスクの最初のバッチを購入する場合、またはアレイを拡張したりハードウェアを更新するために交換品を購入したりする場合、2つの幅広いアプローチがあります。 1つのベンダーから1つの注文ですべてのドライブを購入し、すべてのディスクを含む1つの大きな箱を受け取ります。 さまざまなベンダーから1枚のディスクを注文するか、1枚のディスクの注文を数日または数週間にわたって分散させます。 明らかにいくつかの妥協点がありますが、これらは主な対立する考え方です。私は、アレイの壊滅的な故障のリスクを減らすという点で、どのアプローチがより賢明であるかを本当に知りました。（「アレイの再同期化にかかる時間に等しい時間枠内でディスクの25％が故障する」と定義しましょう。）すべてのディスクが同じ場所から来た場合、すべてが同じであるロジックストライキを待っている根本的な欠陥。あなたがそうするなら、同じ最初の時計のカウントダウンで同じ時限爆弾。 私はそれぞれのアプローチについてより一般的な長所と短所をいくつか収集しましたが、それらのいくつかは、証拠に基づいた堅固なデータではなく、推測と直感のように感じます。 一度にすべて購入、プロ 研究/注文フェーズに費やす時間が短縮されます。 ベンダーが請求する場合の送料を最小限に抑えます。 ディスクは、動作特性（温度、振動など）で同じファームウェアバージョンと同じ「癖」を持つことがほぼ保証されています。 価格の上昇/在庫不足がプロジェクトの途中で停止することはほとんどありません。 次の各ディスクは、インストールする必要がある瞬間に手元にあります。 シリアル番号はすべて既知であり、ディスクはシリアル番号の増加順にエンクロージャーに取り付けることができます。過度にうるさいようですが、一部の人々はそれを重視しているようです。（管理インターフェイスは、ハードウェアポートの順序ではなくシリアル番号でディスクを並べ替えると思います...？） まとめ買い、短所 すべてのディスクは（おそらく）同じ工場で製造され、同じ材料で同時に製造されました。それらは同じ環境に保管され、輸送中に同じ潜在的な悪用の対象となりました。1つに存在する欠陥または損傷はすべてに存在する可能性があります。 ドライブを一度に1つずつ既存のアレイに交換し、新しい各ディスクを個別に再同期化する必要がある場合、注文の最後のディスクがインストールされ、障害があると検出されるまでに数週間かかる可能性があります。ベンダーとの返品/交換ウィンドウはこの期間中に期限切れになる場合があります。 プロジェクト中に発生する可能性がある近未来の価格低下を利用することはできません。 個別に購入、プロ 1つのディスクに障害が発生した場合、他のディスクとほとんど製造/輸送履歴を共有しません。製造または輸送中の何かが原因で障害が発生した場合、根本原因は他のディスクでは発生していない可能性があります。 ディスクが到着時にデッドであるか、使用の最初の数時間で故障した場合、それは出荷が到着した直後に検出され、返品プロセスがよりスムーズに進む可能性があります。 個別に購入、短所 納得のいく価格の十分なベンダーを見つけるのにかなりの時間がかかります。注文の追跡、配送の失敗、破損した商品の返品、その他の問題の解決には時間がかかる場合があります。 潜在的に高い送料。 新しいディスクが必要になるものの、手元にないものがあり、プロジェクトが停止する可能性が非常にあります。 想像上の利益。ベンダーまたは購入した日付に関係なく、すべてのディスクは同じ場所から来ており、実際には同じです。製造上の欠陥は品質管理によって検出され、標準以下のディスクは販売されませんでした。出荷時の損傷は非常にひどく（肉眼ではっきりと見えるように）なければならず、そのため損傷したドライブは開梱時に明らかになります。 単に箇条書きの数で行く場合は、「一括購入」がかなり明確に勝ちます。しかし、長所のいくつかは弱く、短所のいくつかは強いです。箇条書きの多くは、単純に他のいくつかの論理的な逆を示しています。これらのことのいくつかは不条理な迷信かもしれません。しかし、迷信がアレイの整合性を維持する上でより良い仕事をするなら、私はそれに沿って進んでいくと思います。 ここで最も賢明なグループはどれですか？ 更新：この議論に関連するデータがあります。私が個人的に構築した最後のアレイ（約4年前）には8つのディスクがありました。私は単一のベンダーに注文しましたが、購入を約4枚ずつ2注文に分割しました。実行の最初の数時間以内にアレイの1つのディスクが故障しました。それは最初のバッチからのものであり、その注文の返品期間はすべてをスピンアップするのにかかった時間で閉じていました。 4年後、7台の元のディスクと1台の交換ディスクは引き続きエラーなしで実行されています。（木のノック。）

96 raid  hard-drive  best-practices  shipping 

プログラマーとして、私たちはシステム管理者を当たり前だと思う傾向があります。優れたシステム管理者がいなかった数回のおかげで、皆さんが何をしているのか本当に理解できました。システム管理者のいない環境に挑戦するとき、どのような知恵の言葉を提供できますか？

96 best-practices 

これは、Active Directoryドメインの命名に関する標準的な質問です。 仮想環境でWindowsドメインとドメインコントローラーを試した後、DNSドメインと同じexample.com名前のActive Directory ドメインを持つことは悪い考えであることに気付きました（つまり、example.comドメイン名がある場合、Active Directory名として持っていることは意味がありません当社のウェブサイトとして使用するために登録されています）。 この関連する質問はその結論を裏付けているように見えますが、Active Directoryドメインの命名に関して他にどのようなルールがあるのか​​はまだわかりません。 Active Directoryの名前がどうあるべきか、そうでないべきかについてのベストプラクティスはありますか？

89 windows  active-directory  best-practices 

さまざまなハードウェア、ソフトウェア、オペレーティングシステム、仮想/専用など、さまざまなサーバーのパペット管理クラスターの環境を想定します。 意味のあるホスト名（mysqlmaster01..99、mysqlslave001..999、vpnprimary、vpnbackupなど）を選択しますか、または本や映画のキャラクターなどの意味のないホスト名を選択しますか？ 意味のあるホスト名で見られる問題は、通常、名前が単一のサービスを表し、サーバーに複数の目的がある場合、それが本当に面倒になることです（特にサーバーの役割が頻繁に変更される場合）。 サービス名をIPアドレスにマッピングし、そのマッピングを維持して、DNSが行うべきことをしていませんか？ 両方のアプローチの長所と短所は何ですか？また、選択したアプローチで取り組む必要がある実際の問題は何ですか？

79 configuration-management  best-practices 

私はオフィスのコンピューターとネットワークの管理を手伝うためにITの人を雇います。私たちは小さなお店なので、ITを行うのは彼だけです。 もちろん、私は注意深くインタビューし、参考文献をチェックし、バックグラウンドチェックを実行します。しかし、あなたは物事がどのように機能するかを決して知らない。 雇っている人が悪であることが判明した場合、どうすれば会社の露出を制限できますか 彼を組織内で最も強力な人物にすることを避けるにはどうすればよいですか？

76 security  best-practices 

私は、標準的なユーザー名に関する人々の経験が何かを知りたいと思っています。私は常に{firstInitial} {lastname}を使用する場所にいました（長さ制限がある場合もあります）。現在、{firstname}。{lastname}を必要としているユーザーがいます。そして今、その期間が問題を引き起こす可能性があることがわかりました。 具体的には： すべての用途で互換性を維持するために使用する最適なユーザー名の長さ制限は何ですか？ どのキャラクターを避けるべきですか？ 更新：詳細に言及しなかった理由は、将来登場する可能性のあるものをすべて処理するのに十分な汎用性を望んでいたからです。ただし、それは要件の一般的すぎる可能性があります（何か起こる可能性がありますよね？）。 これが私たちの環境です。UbuntuServer Lucid Lynx 10.04 LTS、Red Hat Enterprise Linux 5.6以降、Windows Server 2003およびWindows 2000 Server（Windows 2000ネイティブモードのActive Directory）、メール用のZimbra 7.x、および近くのOpenLDAP未来。 更新：（完全を期すために）私はこの質問を見ました（私の質問には答えませんでしたが）と、このWeb投稿にも言及する必要があります。

59 user-accounts  best-practices 

ケーブル管理の良い例と悪い例を見てきました。 ラック/サーバールーム/データセンターでケーブルの順序を維持するポリシーで使用できる客観的で測定可能な要件は何ですか？ 「スパゲッティの配線をしないでください」を探していません。しかし、実用的で客観的に測定可能なポリシーであり、ポリシーの要件を満たしているか失敗しているかを簡単に説明、追跡、および検査できます。 「x、y、またはzを実行しない」ことは避けてください。代わりに、要件を「Do A、B、およびC」として再構成します。2番目の要件に従うと、最初の要件で説明した問題がなくなります。

48 datacenter  best-practices  rack  cable-management  physical-environment 

AppleとWindows 7のPC /ラップトップを組み合わせて使用​​する従業員がすべてリモートの従業員で構成されているクライアントがいます。 ユーザーは現時点ではドメインに対して認証しませんが、組織はいくつかの理由でその方向に移行したいと考えています。これらは会社所有のマシンであり、会社はアカウントの非アクティブ化、グループポリシー、および軽いデータ損失防止（リモートメディア、USBなどの無効化）をある程度制御しようとしています。特に退職した従業員とリモートマシン上のキャッシュされた資格情報が交差する場所では、面倒です。 組織内のほとんどのサービスはGoogleベース（メール、ファイル、チャットなど）であるため、ドメインサービスはDNSとCisco ASA VPNの認証のみです。 お客様は、ドメインコントローラーを公開することが受け入れられない理由を理解したいと考えています。また、分散リモートワーカーのより受け入れ可能なドメイン構造は何ですか？ 編集： Centrifyは、少数のMacクライアントで使用されています。

46 active-directory  remote-access  best-practices 

System Monkeyとしての短い統治の後、私は今、ジレンマに直面しています。 職場のコンピューターに十分な空きディスク領域がないため、ラップトップでバックアップとテストVMの両方を正常に作成しました。私はまだバックアップを削除しませんでした。会社の歴史上、このバックアップはまだ唯一のものだからです。オリジナルは2006年から継続的に使用されているハードドライブで実行されています。現在、会社に残っているのは1人だけで、バックアップとは何かを知っています。 。 前回、バックアップの重要性について彼らに話をしようとしたとき、彼らは私が彼らを脅していると思った。 保管すべきですか？ 長所： 私は人々を自分の愚かさから救うことができます（私が知る限り、非公式のシステム管理者のモットー） 彼らが助けを懇願するとき、私は「そう言った」と言うようになり、それについて気分が良い すてきな良心 適切な神とのボーナス担当者 短所： 法的問題：私がそれを手伝っても、彼らはそれを維持するために私を訴えるかもしれませんが、私は良いケースを持っていると思いますが 法的問題：仕事の性質とそのセキュリティを考えると、何かが漏れた場合、私は報復の標的になる可能性が高い 法的問題：他に考えなかったことは何でも ポルノのためにもっとスペースが必要です。 法的問題。 あなたならどうしますか？ 更新： すべての返信をありがとう、あなたはすべて本当に役に立ちました。結局、彼らはバックアップを望まないこと、私にそれを保持させたくないこと、彼らが私にそれを持っていることを知っていること、そして今後バックアップを持たない責任を負うことを確認する録音された会話で終わった。コピーを細断しました。

40 best-practices 

データセンターにAnsibleを導入し、制御マシンの場所とSSHキーの管理方法に関するセキュリティのベストプラクティスを探しています。 質問1：制御マシン もちろん、制御機が必要です。制御マシンには、公開SSHキーが保存されています。攻撃者がコントロールマシンにアクセスできる場合、潜在的にデータセンター全体（またはAnsibleが管理するサーバー）にアクセスできます。それでは、データセンターに専用の制御マシンまたはリモート制御マシン（データセンターにリモート接続されたラップトップなど）を使用する方が良いでしょうか？ ベストプラクティスがラップトップを使用することである場合（もちろん盗まれる可能性がありますが、公開キーをクラウドで安全に保存するか、暗号化されたポータブルデバイスでオフラインで保存できます）、Webインターフェイスを使用する必要がある場合Ansible、Ansible Tower、Semaphore、Rundeck、またはForemanのように、中央マシンからデータセンターにインストールする必要がありますか？「単一の攻撃ポイント」になるためにそれを保護し、回避する方法は？ 質問2：SSHキー ルートで実行する必要のあるタスク（ソフトウェアパッケージのインストールなど）を作成するために、Ansibleを使用する必要があるとします。ベストプラクティスは、制御されたサーバーでrootユーザーを使用するのではなく、sudo権限を持つAnsibleの通常ユーザーを追加することだと思います。しかし、Ansibleがほぼすべてのタスクを実行する必要がある場合、sudoを介してすべてのコマンドにアクセスする必要があります。だから、最良の選択は何ですか： Ansibleにrootユーザーを使用させます（公開キーは ~/.ssh/authorized_keys sudoアクセスでAnsible専用の非特権ユーザーを作成します Ansibleユーザーがパスワードを指定してsudoを介してすべてのコマンドを実行できるようにする Ansibleユーザーがパスワードを指定せずにsudoを介してすべてのコマンドを実行できるようにする 他のヒントはありますか？

37 security  ansible  best-practices 

私は通常、自分用に個別のログインを設定し、通常のユーザー権限を持つログインと、管理タスク用に個別のログインを設定します。たとえば、ドメインがXXXXの場合、XXXX \ bpeikesとXXXX \ adminbpアカウントを設定します。率直に言って、自分が管理者としてログインすることを信じていないので、私はいつもそれをしましたが、私が働いたすべての場所で、システム管理者は通常のアカウントをDomain Adminsグループに追加するだけのようです。 ベストプラクティスはありますか？MSの記事で、管理者としてログインするのではなくRun Asを使用する必要があると書かれていますが、実装の例は示しておらず、他の人がそれを行うことはありません。

33 active-directory  security  domain-controller  best-practices 

従業員があなたの組織を退職したとき、Active Directoryアカウントを削除または無効にしますか？私たちのSOPは、Exchangeメールボックスを無効にし、エクスポート/パージし、「しばらく」が経過した後（通常は四半期ごと）、アカウントを削除します。 その遅延の必要性はありますか？メールボックスをエクスポートしてパージした後、その場でアカウントを削除しないのはなぜですか？

32 active-directory  best-practices 

つい最近、ステージングコピーに復元すべきだったときに、開発者が誤ってデータベースを本番環境に復元しようとしました。データベース名が類似している場合（CustomerName_StagingとCustomerName_Production）であれば、簡単に実行できます。 理想的には、これらを完全に別々のボックスに入れますが、それは非常にコストがかかり、厳密に言えば、ユーザーが間違ったボックスに接続した場合に同じことが起こるのを防ぐことはできません。 これ自体はセキュリティの問題ではありません。ステージングデータベースを操作するのは正しいユーザーであり、運用データベースで実行する作業があれば、それも彼の問題になります。これらの懸念を分離するために、展開担当者が必要ですが、チームはそのために十分な大きさではありません。 これを防ぐ方法について、練習、構成、および制御の観点からアドバイスを聞きたいです。

31 sql-server  best-practices