응용 프로그램에서 SSL 연결 전략

Question

특정 응용 프로그램에서 일부 페이지는 보안이 필요하고 다른 페이지는 그렇지 않은 경우 다른 사용자의 의견을 듣고 싶습니다. 별도의 도메인/하위 도메인이 필요한 테이블에서 솔루션을 가져옵니다. 이 경우 보안되거나 안전하지 않은 모든 호출이 동일한 도메인에 연결됩니다. 몇 가지 옵션이 있습니다 :

1. ham-fisted는 모든 접근 방식을 보호합니다.
2. 보안이 필요한 페이지가 https 프로토콜을 통해 액세스되고 다른 페이지를 무시하거나 표준 HTTP에 강제로 액세스하도록하는 URI 다시 쓰기 솔루션
3. 각 링크가 담당하는 응용 프로그램 중심 접근 방식 그것이 가리키고 있는지 그리고 올바른 프로토콜을 적용하고 있는지를 아는 것. 이 솔루션에서 모든 링크는 정규화되어야합니다.
4. 보안 페이지에 대한 링크가 정규화되고 다른 페이지에 대한 링크가 아닌 응용 중심적 접근 방식의 자유 방임 버전입니다. 이 경우 프로토콜은 명시 적으로 처리되지 않는 페이지에 대해 상속되며 중요하지 않은 페이지는 https를 통해 액세스 될 수 있습니다.

나는 이들 중 몇 가지를 때때로 사용했지만 모두 단점이 있습니다. 이 상황에서 다른 사람들은 무엇을하고 있습니까? 내가 고려하지 않은 다른 경로가 있습니까?

는 UPDATE :

vartec의 대답은 아래에 제가 정보를 하나 개의 중요한 부분을 왼쪽했던 것을 깨닫게했다. 내 네트워크 구성에서는 모든 SSL 처리가로드 밸런서 수준에서 처리됩니다. LB는 포트 80을 통해 웹 서버 클러스터와 통신합니다. 결과적으로 응용 프로그램 자체는 트래픽이 안전하게 도착했는지 여부를 모릅니다. 그들이 보는 모든 것은 포트 80 연결입니다.

감사합니다.

Answer 1

# 4와 # 2를 섞어서 사용합니다. 프로토콜을 전환해야 할 때 절대 URL을 지정하고 서버 측 리디렉션을 구현하여 절대 URL을 사용하지 않은 링크를 잡습니다 (또는 누군가가 링크를 따라가 아니라 URL에 직접 액세스합니다.)

필자가보기에, 한 가지 필수적인 것은 안전한 액세스 (양식 제출 등)가 필요한 페이지에 안전하게 액세스 할 수 있다는 것입니다.이 경우 아파치의 SSLRequireSSL 지시어를 사용합니다. SSL을 통하는 경우를 제외하고는 특정 페이지에 액세스하지 않을 것임을 쉽게 확인합니다.

Answer 2

나는 그게 다 접근 안전하지만 그때 당신은 도메인/하위 도메인 솔루션을 제외하고 (이상하게 내 마음에 의해) 테이블에서 내 진짜 솔루션을 가져갔습니다. 사이트 보안상의 오류는 약간의 처리 오버 헤드보다 훨씬 위험합니다.

우리는 안전하지 않은 (그러나 주로 마케팅) 우리의 메인 사이트를 가지고 있고 우리는 다른 하위 도메인 인 어플리케이션 사이트를 가지고 있습니다. 간단하고, 쉽고, 효과적입니다. 테이블에서 그 옵션을 꺼내는 이유는 무엇입니까?

Answer 3

각 페이지의 컨트롤러가 안전해야하는지 여부를 알고있는 응용 프로그램 중심 접근 방식입니다. 보안이 필요하지만 안전하지 않은 http를 통해 액세스하는 경우 https로 리디렉션하여 모든 매개 변수를 전달하십시오.