현실에서는 왜 메소드 레벨 보안을 구현해야합니까?
우리는 웹 애플리케이션 또는 데스크탑 애플리케이션을 가지고 있는데, 여기서 사용자는 사용자 인터페이스에 액세스하므로 메소드에 직접 액세스 할 수 없습니다.
그렇다면 접근 방법은 어디에서 직접 볼 수 있습니까?
편집 : 나는 스프링 보안을 실험하고 있기 때문에이 질문을하고, 사용자에게 메소드 액세스 권한을 부여하는 것을 본다.
같은 :
@ROLE_ADMIN
public void update() {
//update
}
답변:
올바르게 설계된 응용 프로그램에서 백엔드와 프런트 엔드의 연결이 끊어졌습니다. 백엔드 보안 시스템은 특정 프런트 엔드가 보안을 올바르게 처리한다고 가정 할 수 없으므로 자체 처리해야합니다.
컨트롤러의 작업에 대한 역할 기반 액세스에 대해 이야기한다고 가정합니다. 즉, MVC 아키텍처에서 Controller클래스의 각 메소드 는 별도의 조치입니다. 내가 사용한 대부분의 MVC 프레임 워크를 사용하면 메서드 수준과 클래스 수준 모두에서 권한을 할당 할 수 있습니다. 즉, 클래스 수준에서 속성 / 주석을 적용 할 수 있으며 해당 컨트롤러의 모든 작업에 해당 역할이 필요합니다.
역할 기반 액세스에 대한보다 세분화 된 제어와 관련하여 다음을 고려하십시오.
루비 온 레일즈가 몇 년 전에 전파에 부딪쳤을 때, 거의 모든 MVC 프레임 워크가 기본 설계 방식을 복사했습니다. 예전에는 액션이 별도의 클래스 였지만 액션 로직은 작고 집중적 인 경향이 있으므로 전체 클래스 오버 헤드가 과도합니다. 컨트롤러의 메소드를 페이지의 조치에 맵핑하는 것은 실제로 많은 의미가 있습니다. 많은 사람들이 어떤 역할이 어떤 기능을 수행 할 수 있는지에 대한 세밀한 제어가 필요하다는 것을 알고 계십시오.
Mike Wiesner는이 SpringSource 프리젠 테이션 인 Spring Security 3 / 3.1 소개에서 Tomcat 및 기타 여러 서블릿 컨테이너에 유니 코드로 인코딩 할 때 "../"를 올바르게 인식하지 못하는 버그가 있음을 예를 들었습니다. 간단한 등가 테스트는 Java에서 실패하지만 파일 시스템의 상위 디렉토리로 변환됩니다.
보안은 어렵고 여러 수준의 보안으로 우회 시도를 차단할 가능성을 높입니다. 메서드 수준 보안은 클래스 내부에서 직접 코딩되므로 AOP 기능 보강 후에는 메서드를 호출 할 때 항상 보안 검사를 호출해야합니다.
나는 당신이 여기에 공개, 개인 및 보호 방법에 대해 이야기하고 있다고 가정합니까?
그렇다면 보안을 위해 존재하지 않습니다. 소프트웨어의 모듈화가 더 쉬워 지도록하기 위해 존재합니다. (그들이 성공하든 다른 사람들을 위해 떠날 논쟁이지만, 그들이 무엇을위한 것인지에 대한 비전입니다.)
라이브러리를 제공한다고 가정하면 나중에 다른 버전의 라이브러리를 제공하고 개인으로 표시된 항목을 원하는만큼 변경할 수 있습니다. 대조적으로 내가 그 물건을 비공개로 표시하지 않았다면 누군가 어딘가에 직접 액세스하기 때문에 소프트웨어의 내부를 변경할 수 없습니다. 이론적으로 문서화 된 API를 사용하지 않는 것은 잘못입니다. 그러나 클라이언트는 소프트웨어 업그레이드로 인해 소프트웨어가 고장났다는 것을 내 잘못으로 인식합니다. 그들은 변명을 원하지 않고 고정되기를 원합니다. 그러나 그들이 처음부터 액세스 할 수있게하지 않으면 내 API는 내가 API로 의도 한 공개 메소드이며 문제를 피할 수 있습니다.
두 번째로 가장 가능성이 높은 것은 Java의 보안 모델입니다. 당신이 그것에 대해 이야기하고 있다면, 그것이 존재하는 이유는 Java에 대한 원래의 비전은 신뢰할 수없는 애플릿을 보내는 사람들이 타사 프로그램 (예 : 브라우저) 내에서 대화 형으로 작동하도록하는 것이 었습니다. 따라서 보안 모델은 사용자에게 악의적 인 애플릿에 대한 보호 기능을 제공하기위한 것입니다. 따라서 걱정하고 보호해야하는 보안 위협은로드 될 수있는 다른 소프트웨어와 상호 작용하려는 신뢰할 수없는 애플릿입니다.