웹 사이트의 관리 섹션을 보호하기위한 모범 사례는 무엇입니까? [닫은]

특히 인증 / 액세스 관점에서 웹 사이트의 관리 섹션을 보호하기 위해 사람들이 모범 사례를 고려하는 것이 무엇인지 알고 싶습니다.

물론 SSL을 사용하고 모든 액세스를 로깅하는 것과 같은 명백한 것들이 있지만, 사람들이 기준을 설정한다고 생각하는 이러한 기본 단계 바로 위의 위치가 궁금합니다.

예를 들면 :

• 일반 사용자에게 사용하는 것과 동일한 인증 메커니즘에 의존하고 있습니까? 그렇지 않다면 무엇입니까?
• 동일한 '애플리케이션 도메인'에서 관리 섹션을 실행하고 있습니까?
• 관리 섹션을 발견하지 못하도록하기 위해 어떤 단계를 수행합니까? (또는 '모호함'전체를 거부합니까?)

지금까지 답변자의 제안은 다음과 같습니다.

• 무차별 대입 공격을 방지하기 위해 각 관리자 암호 확인에 인위적인 서버 측 일시 중지를 도입합니다. [개발자 아트]
• 동일한 DB 테이블을 사용하여 사용자 및 관리자에 대해 별도의 로그인 페이지 사용 (관리 영역에 대한 액세스 권한을 부여하는 XSRF 및 세션 탈취 중지) [Thief Master]
• 또한 관리 영역에 웹 서버 네이티브 인증을 추가하는 것도 고려해보십시오 (예 : .htaccess를 통해) [Thief Master]
• 여러 번의 관리자 로그인 시도 실패 후 사용자 IP 차단 고려 [Thief Master]
• 관리자 로그인 시도 실패 후 보안 문자 추가 [도용자]
• 사용자와 관리자에게 똑같이 강력한 메커니즘 (위의 기술 사용)을 제공합니다 (예 : 관리자를 특별히 대하지 않음) [Lo'oris]
• 2 단계 인증 고려 (예 : 클라이언트 인증서, 스마트 카드, 카드 공간 등) [JoeGeeky]
• 신뢰할 수있는 IP / 도메인에서만 액세스를 허용하고 가능하면 기본 HTTP 파이프 라인 (예 : HttpModules를 통해)에 검사를 추가하십시오. [JoeGeeky]
• [ASP.NET] IPrincipal 및 Principal 잠그기 (불변 및 열거 불가능하게 만들기) [JoeGeeky]
• 권한 상승 연합-예를 들어 관리자의 권한이 업그레이드되면 다른 관리자에게 이메일을 보냅니다. [JoeGeeky]
• 관리자를위한 세분화 된 권한 고려-예를 들어 역할 기반 권한보다는 관리자 별 표시 작업에 대한 권한 정의 [JoeGeeky]
• 관리자 생성 제한-예를 들어 관리자는 다른 관리자 계정을 변경하거나 생성 할 수 없습니다. 이를 위해 잠긴 'superadmin'클라이언트를 사용하십시오. [JoeGeeky]
• 클라이언트 측 SSL 인증서 또는 RSA 유형 keyfob (전자 토큰) 고려 [Daniel Papasian]
• 인증을 위해 쿠키를 사용하는 경우 관리 페이지와 일반 페이지에 대해 별도의 쿠키를 사용하십시오 (예 : 다른 도메인에 관리 섹션을 배치). [다니엘 파파 시아]
• 가능하다면 관리 사이트를 공용 인터넷이 아닌 사설 서브넷에 유지하는 것이 좋습니다. [존 하트 삭]
• 웹 사이트의 관리자 / 정상 사용 컨텍스트간에 이동할 때 인증 / 세션 티켓 재발급 [Richard JP Le Guen]

이것들은 모두 좋은 대답입니다. 저는 일반적으로 관리 섹션에 대해 몇 가지 추가 레이어를 추가하는 것을 좋아합니다. 테마에 몇 가지 변형을 사용했지만 일반적으로 다음 중 하나가 포함됩니다.

• 2 단계 인증 : 여기에는 클라이언트 인증서 (예 : x509 인증서), 스마트 카드, 카드 공간 등이 포함될 수 있습니다.
• 도메인 / IP 제한 :이 경우 신뢰할 수있는 / 확인 가능한 도메인에서 오는 클라이언트 만; 내부 서브넷과 같은; 관리 영역에 허용됩니다. 원격 관리자는 종종 신뢰할 수있는 VPN 진입 점을 통과하므로 세션을 확인할 수 있고 종종 RSA 키로도 보호됩니다. ASP.NET을 사용하는 경우 HTTP 모듈을 통해 HTTP 파이프 라인에서 이러한 검사를 쉽게 수행 할 수 있습니다. 그러면 보안 검사가 충족되지 않을 경우 응용 프로그램이 요청을 수신하지 못합니다.
• 잠긴 IPrincipal 및 Principal 기반 권한 : 사용자 지정 원칙을 만드는 것은 일반적인 관행이지만 일반적인 실수는 수정 가능 및 / 또는 권한을 열거 가능하게 만드는 것입니다. 단순한 관리자 문제는 아니지만 사용자가 높은 권한을 가질 가능성이있는 곳이기 때문에 더 중요합니다. 변경 불가능하고 열거 불가능한지 확인하십시오. 또한 승인에 대한 모든 평가가 교장을 기준으로하는지 확인하십시오.
• 권한 상승 연합 : 계정이 선택된 수의 권한을 받으면 모든 관리자와 보안 담당자에게 즉시 이메일로 통보됩니다. 이렇게하면 공격자가 권한을 높이면 즉시 알 수 있습니다. 이러한 권리는 일반적으로 권한이있는 권리, 개인 정보 보호 정보를 볼 수있는 권리 및 / 또는 금융 정보 (예 : 신용 카드)를 중심으로합니다.
• 관리자에게도 권한을 아껴서 발행 : 마지막으로, 일부 상점에서는 조금 더 발전 할 수 있습니다. 권한 부여 권한은 가능한 한 신중해야하며 실제 기능 동작을 포괄해야합니다. 일반적인 RBS (역할 기반 보안) 접근 방식은 그룹 정신 을 갖는 경향이 있습니다 . 보안 관점에서 이것은 최상의 패턴이 아닙니다. ' 사용자 관리자 '와 같은 ' 그룹 ' 대신 더 세분화하십시오 ( 예 : 사용자 만들기, 사용자 권한 부여, 액세스 권한 상승 / 취소 등).). 이것은 관리 측면에서 약간 더 많은 오버 헤드를 가질 수 있지만 더 큰 관리자 그룹에 실제로 필요한 권한 만 할당 할 수있는 유연성을 제공합니다. 액세스가 적어도 손상되면 모든 권한을 얻지 못할 수 있습니다. 나는 이것을 .NET 및 Java에서 지원하는 CAS (Code Access Security) 권한으로 래핑하고 싶지만이 답변의 범위를 벗어납니다. 한 가지 더 ... 한 앱에서 관리자는 다른 관리자 계정을 변경하거나 사용자를 관리자로 만들 수 없습니다. 두 사람 만 액세스 할 수있는 잠긴 클라이언트를 통해서만 수행 할 수 있습니다.

웹 사이트에 일반 활동과 관리자 모두에 대한 로그인이 필요한 경우 (예 : 포럼) 동일한 사용자 데이터베이스를 사용하는 별도의 로그인을 사용합니다. 이렇게하면 XSRF 및 세션 탈취로 인해 공격자가 관리 영역에 액세스 할 수 없습니다.

또한 admin 섹션이 별도의 하위 디렉토리에있는 경우 웹 서버의 인증 (예 : Apache의 경우 .htaccess)을 사용하여 해당 섹션을 보호하는 것이 좋은 생각 일 수 있습니다. 그러면 누군가 해당 비밀번호와 사용자 비밀번호가 모두 필요합니다.

관리자 경로를 가리는 것은 보안 이득을 거의 얻지 못합니다. 누군가 유효한 로그인 데이터를 알고 있다면 관리자 도구를 피싱하거나 키 로깅했거나 사회 공학을 통해 가져 왔기 때문에 관리자 도구의 경로를 찾을 가능성이 가장 높습니다. 경로도).

3 번의 로그인 실패 후 사용자의 IP를 차단하거나 로그인 실패 후 CAPTCHA를 요구하는 것과 같은 무차별 대입 보호 (합법적 인 사용자에게는 매우 성가신 일이므로 처음 로그인하는 경우가 아님)도 유용 할 수 있습니다.

• 나는 모호함을 거부한다
• 하나가 아닌 두 개의 인증 시스템을 사용하는 것은 과잉입니다
• 시도 사이의 인위적인 일시 중지도 사용자를 위해 수행되어야합니다.
• 실패한 시도의 IP 차단은 사용자도 수행해야합니다.
• 사용자도 강력한 암호를 사용해야합니다.
• 캡차를 괜찮다고 생각한다면 사용자에게도 사용할 수 있습니다.

예, 작성한 후이 답변이 "관리자 로그인에 특별한 것은 없으며 모든 로그인에 사용해야하는 모든 보안 기능"으로 요약 될 수 있음을 깨달았습니다.

일반 사용자 권한과 관리자 권한을 모두 가진 사용자에 대해 단일 로그인 만 사용하는 경우 수준이 변경 될 때 세션 식별자 (쿠키 또는 GET 매개 변수 등 ...)를 다시 생성하십시오. 특권 ... 최소한.

따라서 로그인하면 일반적인 사용자 작업을 한 다음 관리자 페이지를 방문하여 세션 ID를 다시 생성하십시오. 그런 다음 관리자 페이지에서 일반 사용자 페이지로 이동하면 내 ID를 다시 생성하십시오.

좋은 관리자 암호가 있습니다.

하지 "123456"만 충분히 문자, 숫자, 특수 문자의 순서, 15 ~ 20 개 문자 말한다. 처럼 "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".

무차별 대입 공격을 방지하기 위해 각 암호 확인에 대해 일시 중지를 추가합니다.

고려해야 할 몇 가지 다른 사항은 다음과 같습니다.

1. 특히 관리자의 컴퓨터를 관리하거나 기술적으로 유능한 경우 고려할 한 가지 옵션은 클라이언트 인증을 위해 SSL 인증서를 기반으로하는 것을 사용하는 것입니다. RSA keyfob 및 기타 기능은 추가 보안을 위해 사용할 수도 있습니다.
2. 인증 / 세션 토큰을 위해 쿠키를 전혀 사용하고 있다면 쿠키가 관리자 페이지로만 전송되도록하고 싶을 것입니다. 이렇게하면 레이어 1/2 손상 또는 XSS로 쿠키를 훔쳐 사이트에 대한 위험을 완화하는 데 도움이됩니다. 이는 관리 부분이 다른 호스트 이름 또는 도메인에 있도록하고 쿠키로 보안 플래그를 설정하여 쉽게 수행 할 수 있습니다.
3. IP로 제한하는 것도 현명 할 수 있으며, 인터넷에 사용자가있는 경우 해당 사용자가 가입 할 수있는 신뢰할 수있는 VPN이있는 경우에도이를 수행 할 수 있습니다.

우리 Windows Authentication는 관리자 액세스에 사용 합니다. 이것은 일반 최종 사용자에게 적용되는 것과 별도로 인증을 유지하면서 관리 영역을 보호하는 가장 실용적인 방법입니다. 시스템 관리자는 관리자 사용자 액세스 자격 증명을 관리하고 도메인 사용자 계정에 암호 정책을 적용합니다.

엄격한 방법은 데이터베이스, 서버 및 모두를 포함하여 두 개의 완전히 다른 "팜"을 보유하고 한 팜에서 다른 팜으로 데이터를 이동하는 것입니다. 대부분의 최신 대규모 시스템은이 접근 방식을 사용합니다 (비 네트, SharePoint 등). 일반적으로 "편집 단계"-> "미리보기 단계"-> "배달 단계"가 다른 단계를 갖는 것으로 지칭됩니다. 이 방법을 사용하면 코드 (dev-> qa-> prod)를 처리하는 것과 동일한 방식으로 콘텐츠 / 구성을 처리 할 수 ​​있습니다.

편집증이 적은 경우 단일 데이터베이스를 사용할 수 있지만 "편집"서버에서 관리 섹션 만 사용할 수 있습니다. 즉, 편집 서버에는 편집 스크립트 / 파일 만 배치해야합니다.

당연히 편집 단계는 로컬 인트라넷 및 / 또는 VPN을 통해서만 가능해야합니다.

이것은 약간의 과잉으로 보일 수 있으며 모든 사용 사례에 대한 가장 쉬운 솔루션은 아니지만 분명히 가장 강력한 작업 방법입니다.

"강력한 관리자 암호 사용"과 같은 것은 좋지만 여전히 모든 종류의 현명한 속성에 관리자를 열어 두십시오.

보호하려는 데이터의 종류 (법적 요구 사항 등)에 따라 다릅니다.

• 많은 제안은 인증에 관한 것입니다. 저는 OpenId / Facebook 인증을 로그인으로 사용하는 것을 고려해야한다고 생각합니다. (그들은 인증 보안에 더 많은 리소스를 소비 할 가능성이 높습니다.)

• 변경 사항을 저장하고 데이터베이스의 값을 업데이트합니다. 이렇게하면 사용자 X 또는 날짜 X와 Y 사이의 변경 사항을 롤백 할 수 있습니다.

나는 아무도 관리자 암호의 저장 / 유효성에 대해 언급 한 것을 보지 못했습니다. 제발 PW를 일반 텍스트로 저장하지 마시고, 되돌릴 수있는 것조차하지 마십시오. 적어도 누군가가 가지고 있지 않은 저장된 "비밀번호"를 검색 할 수 있도록 솔트 된 MD5 해시 와 같은 것을 사용 하십시오. 그들이 당신의 소금 계획을 가지고 있지 않는 한 몹시 유용한 것.

관리자가 알 수있는 비밀번호 필드와 보안 질문 (예 : 첫 번째 여자 친구 이름이 무엇인지)을 추가하거나 관리자 패널을 볼 때마다 질문을 무작위로 지정합니다.

아마도 당신은 항상 관리 섹션을 큰 디렉토리에 둘 수 있습니다.

http://domain.com/sub/sub/sub/sub/sub/index.php

하지만 그건 정말 좋지 않아요.

다음과 같이 홈페이지에 쿼리 문자열을 포함 할 수 있습니다.

http://domain.com/index.php?display=true

그러면 사용자 이름과 암호 필드가 나타납니다.