題:
擁有“上帝”密碼的錯誤做法？
Abe Miessler
2014-02-07 23:08:51 UTC
view on stackexchange narkive permalink

擁有允許您訪問網站上任何用戶帳戶以獲取支持的密碼是否違反安全慣例？密碼將以安全的方式存儲，並且會非常複雜。大錯誤？

為什麼不僅僅擁有一個有權修改其他用戶數據的管理員帳戶？
這樣做似乎會在支持人員和問題帳戶之間增加另一層，而不會提供更多的安全性。您為什麼認為這會更安全？
@Polynomnial通常，管理員會“看到”與用戶不同的屏幕，有時，對於支持人員查看他們遇到問題時所看到的確切屏幕會有所幫助。 （不說'上帝'pw是個好主意，但是Admin帳戶不能解決此特定問題-*除非* Admin可以模擬帳戶。）
已經有一種方法可以做到這一點。在任何體面的多用戶操作系統上，它都稱為“ sudo”。
@Polynomial或更好的是，不要使用管理員用戶，但要給支持人員權限。這樣一來，就可以保留記錄，而不是“管理員根據[傳真請求]更改X的DNS記錄”來顯示誰做了什麼（http://www.theguardian.com/technology/2013/oct/15/metasploit-kdms-dns-砍死了傳真）。”編輯：哦，看來這已經在答案中提到了。
@Shadur [不是sudo Unix的東西嗎？]（http://en.wikipedia.org/wiki/Sudo）
-1
當問這種問題時，想像一下您正在與內部審計員交談並試圖解釋為什麼要使用此功能有時會有所幫助。您：“因此，我們獲得了這個“上帝”密碼”。內部審計員：“'上帝'密碼-有點像後門，對嗎？”您：“嗯，很好，但是，但是...”審計員：“保證！關閉'IS'EAD !!!!!！從所有角度來看，不是嗎？
十 答案:
tylerl
2014-02-08 00:02:42 UTC
view on stackexchange narkive permalink

這聽起來很像一個“管理員”帳戶，否則通常可以不受限制地訪問它作為管理員的內容。

管理員帳戶的安全隱患是很容易理解的，因為是最佳做法。我不會詳細介紹所有細節，但是您的實現會在一個關鍵功能（可追溯性）上偏離最佳實踐。

您想知道誰做了什麼，尤其是關於管理員。如果管理員可以使用他的密碼登錄到我的帳戶，那麼審核員將無法事後確定我是做什麼的，而不是管理員是做什麼的。

管理員使用他的超級安全密碼登錄到自己的OWN帳戶，然後通過他通過自己的帳戶進行的訪問執行我也可以執行的某些操作-那麼現在我們可以看到一個日誌，告訴誰做了什麼。當糞肥碰到風扇時，這是很關鍵的。甚至更重要的是，當一個管理員帳戶遭到入侵時（儘管您盡了最大努力，它也會會）。

此外，請說業務增長了，您需要2個管理員。他們共享超級密碼嗎？不不不。他們倆都有自己的管理員帳戶，分別具有跟踪和日誌記錄功能。現在，您可以告訴WHICH管理員做了什麼。而且，最重要的是，當您解僱一名竊取甜甜圈的管理員時，您可以關閉其中一個帳戶。

與此相關的是，雖然通常有必要讓管理員更改帳戶密碼，但是從政策上講，管理員不應該將帳戶設置為直接可使用的密碼，而是將其設置為用戶必須設置自己的密碼。使用該帳戶之前，請輸入自己的密碼。這樣，使用帳戶進行的任何操作都可以歸因於設置帳戶密碼的最新人員。如果Bob不願意使用自己未設置的任何密碼登錄，則他的密碼將在周一更改，而在周四已知他將登錄，這些事實共同暗示...
...鮑勃在星期一設置了密碼，而從那時到星期四之間該帳戶的所有操作都是鮑勃完成的。
如果出於“支持目的”，OP不僅意味著能夠做用戶可以做的事，而且還能夠看到用戶所看到的確切屏幕（例如，幫助用戶解釋如何做某事或幫助弄清楚他們為什麼可以做）怎麼辦？不做某事）？
@joshuahedlund如果管理員要訪問用戶帳戶，則他將更改用戶密碼。然後，他可以告訴用戶他的新密碼是什麼。
@joshuahedlund這就是VNC，TeamViewer，遠程協助，WEbEx等屏幕共享工具的用途。您永遠不會冒充用戶。您查看他/她的屏幕副本，就好像您站在他們後面看著他們的肩膀一樣。
-1
我要補充一點，我強烈建議您限制將管理員帳戶的登錄限制為特定的源IP地址，例如貴公司的IP地址範圍和管理員的家庭IP地址。此外，為管理員帳戶啟用兩因素身份驗證，並在服務器和客戶端使用具有TLS 1.2支持的HTTPS。
該帳戶已被終止，其原因如下：未經授權訪問甜甜圈。
@Thomas:不，不。不是未經授權的訪問，而是使其他用戶無法使用甜甜圈服務。
根據應用程序的類型，我可以看到有一個問題，即跟踪用戶執行他們不應該執行的操作，但是如果有一個“神”密碼可以讓管理員模擬該用戶，則該人有合法的理由要否認這些日誌的可靠性。
@TecBrat正是為什麼您需要將它們分開。如果有人使用您的應用程序分發例如兒童色情作品，那麼只要您能證明只有該用戶參與其中，您就有更大的機會變得乾淨。
@AJMansfield。是。這就是我要說的重點。
這是一個有趣的觀點。我以前曾在一家公司工作過IT，該公司說我們沒有管理員帳戶/後門程序，因此，如果計算機上發生故障，計算機所有者可以毫不猶豫地承擔所有責任。因此，這沒有任何意義，因為正如您所說，如果有一個管理員帳戶，它的操作將被記錄下來（從理論上講，只有IT人員才能知道該密碼）。
Daniel Nalbach
2014-02-08 05:19:43 UTC
view on stackexchange narkive permalink

到目前為止，在給出的答案中有很多有用的信息，原始的發帖人應該閱讀並記住。但是，我認為大多數答案並沒有抓住問題的實質，因為該問題與出於支持目的“像他們是用戶一樣”遍歷其公司的網站有關。問題的核心似乎在於此活動發生在網站的前端而不是服務器的控制台。

我知道一家公司在Web應用程序中也有同樣的需求，我已經以某種方式解決了該問題，我相信這是原始海報所尋找的解決方案。

他們在Web應用程序中創建了一個“假面舞會”系統，該系統允許特殊組中的員工輸入一組頁面，這些頁面可以查找系統中的任何用戶，然後選擇該用戶作為憑據來瀏覽系統配合。它跟踪選擇要偽裝的用戶和實際僱員用戶為兩個單獨且同時存在的實體，這兩個實體始終記錄在每個動作中。

從應用程序的角度來看，這是“以我這個用戶的身份對待我，但請記住我實際上是另一個用戶”。

此方法：

  1. ，這是Web應用程序版本的sudo，但內置在前端。
    1. 消除了審計追踪的噩夢，因為始終跟踪兩個用戶帳戶。
    2. 為員工提供頁面的準確“用戶視圖”。
    3. 維護員工的個人憑證，因此沒有共享或“主”密碼。
    4. 為用戶提供安全性，這些用戶的密碼永遠不會對員工可用。
    5. 將解決方案保留在網站上的應用程序層，這樣任何人都可以在沒有系統級訪問或知識的情況下進行操作。
    6. 員工還可以隨時“偽裝”根據自己的帳戶或其他用戶帳戶檢查頁面內容，這對於確定錯誤是全局錯誤還是特定於用戶的錯誤非常有用。
      7. ol>
在我看來，這個答案是最接近OP問題的答案。管理帳戶不是解決方案，因為它具有與要進行故障排除的用戶之一不同的可見性/行為。
我同意這個答案。在我的工作中，我們的網站內置了類似的功能，允許管理員“模擬”任何其他用戶。它允許管理員以與模擬用戶完全相同的方式查看和使用該站點，同時仍然允許適當的安全性和日誌記錄。
舉一個很好的例子，phpBB論壇軟件內置了此功能。
user10211
2014-02-07 23:13:10 UTC
view on stackexchange narkive permalink

是的，這是一個錯誤。如果攻擊者設法保留了該密碼，無論您認為多麼安全，該怎麼辦？他將能夠以一種極有可能與正常活動區分開的方式篡改用戶帳戶信息。

如果您控製網站，則您已經可以使用多種方法來獲得支持選項。可以編寫適當的管理工具來讀取和修改必要的信息。擁有“主”密碼並沒有多大意義。

適當的管理工具不會構成相同（或至少非常相似）的威脅嗎？
@AbeMiessler否...因為如果您使用單個管理員帳戶，則日誌記錄會顯示發生了什麼情況以及將其密碼張貼在便利貼上時會觸發的人。
Tom Leek
2014-02-08 00:09:21 UTC
view on stackexchange narkive permalink

此“神”密碼等效於root /管理員訪問權限：可以執行所有操作。問題是雙重的：

  1. 具有某種“可以做所有事情”的訪問方式是一個好主意嗎？實際上，它比“好”更“不可避免”，但是是的，這是正常的事情。但是，請確保有適當的使用過程：您不希望管理員從咖啡店的共享計算機上進行管理；而您想知道“誰不知道”。從這個意義上講，當有兩個或多個具有管理員特權的人時，最好是他們作為管理員 group 的成員“作為自己”（在Unix世界中，使用 sudo ，以便記錄命令）。

  2. 讓管理員通過普通用戶API 行使權限是個好主意嗎？這是值得商bat的。允許“上帝密碼”意味著在整個應用程序中安裝“上帝例外”，這有被濫用的風險。它增加了站點中身份驗證+授權系統的複雜性，而復雜性是您在安全性方面要避免的一件事。錯誤在復雜性中蓬勃發展。 “上帝密碼”在開發過程中可能很方便，但是通常來說，它傾向於增加破壞性安全漏洞的可能性，因此使用時要格外小心。

    3. ol>

    當然，上下文是一切，上面的答案通常通常適用。不過，請警惕管理後門，尤其是後門，這些後門不能很好地記錄管理請求的來源。

您對“不可避免”與“良好”的評論提出了一個有趣的觀點。如果系統的設計使得具有物理訪問權限的人將能夠做任何事情，包括不可檢測地修改審計跟踪，那麼允許具有物理訪問權限的人可以方便地進行此類事情可能是合理的。使這些事情不方便但並非不可能會帶來不便，但無法獲得由它們帶來的可追溯性優勢。我有時認為一件事對某人來說是有用的產品...
...要出售的是一個“日誌盒”，其設計目的是確保在一定時間內無法刪除任何已提交的日誌記錄，而不會對其進行物理破壞。例如，如果設備被限制為以30MB /分鐘的速度接受數據，則具有64GB閃存的設備可以保證某人要覆蓋一天的持續最大數據速率泛洪，才能覆蓋日誌條目。如果盒子在其讀取/狀態功能中包含公鑰加密，那麼有人可能完全無限制地訪問帶有此盒子的機器...
...但是，如果日誌記錄了誰獲得了這種訪問權限，那麼該記錄將幾乎是不可磨滅的（如果其他機器定期輪詢該日誌記錄，並且如果它無法訪問數小時便會發出尖叫聲，這可能會通知安全人員發現有什麼不妥之處，並且他們有一定的時間介入，以免銷毀審核信息。
The Spooniest
2014-02-08 03:06:57 UTC
view on stackexchange narkive permalink

管理員仍然只能扮演自己的角色：具有上帝密碼的人可以模擬系統上的任何人。有人可能會爭辯說，如果管理員擁有足夠的權力，那麼用這個帳戶限制攻擊者可能造成的實際損失並沒有多大作用。但是，使用上帝密碼的攻擊者可以更輕鬆地掩蓋自己的足跡。

broc.seib
2014-02-09 01:28:11 UTC
view on stackexchange narkive permalink

擁有“上帝”密碼是一個簡單的解決方案，但是它僅是通過了解主密碼而獲得的“授權”，並不適合進行良好的訪問管理（即控制誰可以做到） （誰確實做了什麼）。

相反，更改您的憑據數據結構以具有有效用戶字段：

  {用戶：alice，effective_user：bob，}

應該為 effective_user 呈現網頁的內容，除非它是一個內部管理頁面，需要知道誰是真正的瀏覽。請注意，大多數瀏覽您網站的外部用戶在兩個字段上始終具有相同的ID：

  {用戶：alice，有效用戶：alice，}

此安排可以使您更好地控制允許誰成為另一個用戶，還可以使您記錄/審核誰代表誰做了什麼。 （您可以簡單地在您要監視的內容上同時記錄user和effective_user。）如果您查看定義過程的源，Unix會在內部執行這種有效的用戶（和組）事務。在網上模仿這一點是利用已知的成功範例。

此解決方案還使您可以選擇員工可以“翻身”另一個用戶的頁面。您可以選擇編寫一個不基於 effective_user 呈現的頁面，即使您的員工有權更改其有效用戶ID，也無法看到該頁面。

順便說一句，我已經在網絡上實現了有效的用戶概念，並且還實現了上帝密碼。當所有基礎結構均已就緒時，可以輕鬆插入後者。但是，就知道誰做了什麼和管理訪問而言，這實際上不是最佳的解決方案。仔細研究添加有效用戶字段實際上涉及多少重構，它可能比您想像的要少。

Tonny
2014-02-08 05:18:44 UTC
view on stackexchange narkive permalink

您永遠不會冒充用戶。 （由於其他已經提到的可追溯性/問責制的各種原因。）
相反，您查看的是用戶屏幕屏幕的副本，就像您站在他們後面看著他們的肩膀一樣。
這就是屏幕/桌面共享工具，例如VNC，TeamViewer，遠程協助等。

我認為您尚未考慮過該聲明的實用性。例如，當我在Facebook上並且想查看權限的結果而不是使用“ view as ...”時，我應該去問問我的一位朋友安裝vnc並訪問我的頁面嗎？儘管屏幕共享可能適合進行故障排除，但在許多情況下，以給定用戶的身份查看網站的行為絕不應該涉及用戶本身。測試/驗證設置或錯誤修正。
AJ Henderson
2014-02-08 01:04:10 UTC
view on stackexchange narkive permalink

如果只有一個人可以訪問，那麼這不一定是問題，但是可以通過對允許該訪問的用戶帳戶進行設置來輕鬆實現。

使用任何根用戶/ superuser / admin這種功能，對行為進行記錄和審核至關重要，這意味著您需要知道誰在做什麼。如果多個用戶需要能夠進行這樣的更改，則應在其帳戶上標記為允許該更改。

您可能仍希望擁有一個額外的，更複雜的密碼，該密碼必須為即使他們有權訪問，也要輸入此密碼，但是在進行這種性質的操作之前，您應該要求對進行更改的個人進行安全身份驗證。

Timothy Swan
2014-02-09 05:48:12 UTC
view on stackexchange narkive permalink

您可能別無選擇，只能輸入“上帝”密碼。不管tylerl關於擁有兩個不同的管理員密碼的說法是什麼，除非有人也負責，否則怎麼可能會有日誌和跟踪記錄？從字面上看，您必須對日誌和所有內容進行加密，以使它只能被外界讀取，但仍然可以自行寫入。它如何確定接收到的信息是否合法？顯然，如果您沒有訪問權限，那麼沒人會這樣做，也將不起作用。

James
2014-02-16 20:12:44 UTC
view on stackexchange narkive permalink

我認為您需要具有基於角色的安全性，而不是具有“神”模式功能的帳戶。這樣，您可以讓多個具有相同角色的人具有相似的功能，這樣，如果您的上帝/管理員不可用，其他人可以進行修復。

我知道這是首選如果您要接受審核。



ⓘ
該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到，我們感謝它分發的cc by-sa 3.0許可。
Loading...