웹 애플리케이션 보안을 보장하는 방법을 알려주세요.

웹 애플리케이션은 오늘날 대부분의 엔터프라이즈 애플리케이션의 선두에 있습니다. 웹 애플리케이션은 복잡한 하이브리드 아키텍처에서 다양한 기능을 수행할 수 있습니다. 최신 클라우드 기술에서 실행되는 서비스 지향 솔루션부터 기존 다중 계층 웹 애플리케이션, 고객이 메인프레임의 레거시 애플리케이션에 액세스할 수 있는 웹 포털에 이르기까지 다양한 애플리케이션이 있습니다.

이러한 복잡한 웹 애플리케이션과 관련된 위험을 관리하는 것은 기업의 불가피한 요구 사항이며, 이러한 웹 애플리케이션을 실행하는 기본 코드의 보안은 회사 애플리케이션에 사용 가능한 데이터의 위험 프로필에 직접적인 영향을 미칩니다. 불행하게도 웹 애플리케이션을 위한 반복 가능하고 효율적인 보안 방식을 개발하는 것은 간단한 작업이 아닙니다. 많은 조직에서는 웹 애플리케이션 방화벽, 침입 방지 시스템과 같은 보안 제어 기능을 제공하기 위해 후반 작업 솔루션을 사용하려고 합니다.

그러나 보안 메커니즘을 배포하기 위해 라이프사이클의 생산 단계까지 기다리는 것은 너무 늦고 그 효과도 너무 작습니다. 설계 또는 아키텍처 문제는 애플리케이션이 프로덕션 단계에 들어갈 때까지 기다리는 것보다 수명주기 초기에 해결하기가 더 쉽습니다. 웹 애플리케이션의 보안 취약성은 데이터 유출, 정책 위반으로 이어질 수 있으며 배포 후 패치 또는 포괄적인 코드 수정으로 인해 전체 비용이 크게 증가할 수 있습니다.

　효과성과 효율성을 보장하려면 웹 애플리케이션의 보안은 요구 사항 정의 단계부터 최종 승인 단계까지 시작되어야 합니다. 이 접근 방식을 사용하려면 모든 디자이너가 프로세스 전반에 걸쳐 팀으로 함께 작업할 수 있어야 합니다. 구현 및 테스트와 같은 단계에서 전략을 따르는 자동화된 도구를 사용하면 반복 가능한 테스트를 지원하고 테스트 프로세스가 표준화됨에 따라 개발 주기가 더 빨라질 수 있습니다.

개발 프로세스의 초기 단계부터 보안을 구축하는 것이 복잡할 필요는 없습니다. 개발 주기 전반에 걸쳐 보안 점검과 균형을 구현하면 릴리스 주기가 빨라지고 웹 애플리케이션 취약성을 크게 줄일 수 있습니다.

　개발 주기 후반부에 보안 테스트를 구현하는 데 드는 높은 비용

　보안 체크포인트를 개발 프로세스에 통합하면 실제로 전체 배송 시간을 줄일 수 있습니다. 반직관적으로 들릴 수도 있지만 웹 애플리케이션을 프로덕션에 배포한 후 설계 오류 및 코딩 오류를 수정하는 데 드는 비용은 매우 높습니다.

예를 들어 많은 개발 환경에서는 보안 및 감사 전문가가 개발 주기 마지막에 나타나는 경향이 있습니다. 이 시점에서 애플리케이션은 완료되며 모든 지연은 불필요한 병목 현상으로 간주됩니다. 소프트웨어 제품을 신속하게 출시하라는 기업의 강한 압력은 보안 제어를 간과하여 웹 애플리케이션이 적절한 보안 검토를 받지 못하게 될 수 있음을 의미합니다. 시간에 매우 민감한 환경에서는 검사 도구가 검증 및 우선순위 지정 없이 수많은 취약점을 보고하더라도 이러한 검사는 득보다 해를 끼칠 수 있습니다.

개발 주기 전체에 걸쳐 함께 작업하는 대신 개발 프로세스 후반부에 보안 감사를 수행하면 특히 심각한 버그가 발견된 경우 릴리스 시간이 지연될 수 있습니다. 개발 주기 후반에 설계 및 코딩 오류를 수정하는 데 드는 비용은 초기에 발견하는 데 드는 비용보다 훨씬 높습니다. 국립과학재단(National Science Foundation)의 연구에 따르면 요구 사항 및 설계 단계에서 심각한 소프트웨어 문제가 발견되어 수정되면 소프트웨어가 생산에 투입된 후에 문제가 발견되는 경우보다 비용이 약 100배 더 저렴하다고 추정됩니다.

웹 애플리케이션에 보안을 구축할 때 대부분의 경우 목표는 뚫을 수 없는 웹 애플리케이션을 구축하거나 가능한 모든 취약점을 제거하는 것이 아닙니다. 대신 목표는 필수 특성을 웹 애플리케이션에 대해 허용되는 위험 프로필과 일치시키는 것입니다. 웹 응용 프로그램의 개발 주기 전반에 걸쳐 목표는 소프트웨어 보증, 즉 특정 웹 응용 프로그램에 적합한 기능 및 민감도 수준을 달성하는 것이어야 합니다. 소프트웨어도 공격을 받을 수 있습니다.

　통합 접근 방식의 이점

　다양한 그룹의 개발자가 팀으로 함께 작업하면 웹 애플리케이션 개발 프로세스의 효율성이 높아집니다. 보안 전문가들은 비즈니스 리더들이 단순히 소프트웨어 위험을 이해하지 못한다고 불평하는 경우가 많지만, 보안 전문가가 비즈니스 위험에 대해 잘 알고 있는 것도 중요합니다. 적절한 수준의 소프트웨어 보증으로 웹 애플리케이션을 구축하려면 비즈니스 요구 사항, 가용성 및 보안 간의 위험 관리 절충이 필요합니다. 적절한 균형을 이루려면 모든 개발자의 요구 사항을 모아야 합니다.

　소프트웨어 개발 초기부터 요구사항 정의 및 애플리케이션 설계에서는 보안 요구사항은 물론 기능 요구사항 및 비즈니스 요구사항도 고려해야 합니다. 이 정보는 코드를 작성하기 전에 디자이너와 소프트웨어 개발자에게 전달되어야 합니다. 이 접근 방식을 사용하면 보안 설계 취약점과 아키텍처 취약점의 대부분 또는 전부를 예방할 수 있습니다.

　그러나 보안에 초점을 맞춘 소프트웨어 설계가 웹 애플리케이션과 관련된 모든 취약점을 제거하는 것은 아닙니다. 개발자는 애플리케이션 설계 중에 보안 취약점이 발생하지 않도록 보안 코딩 기술에 대한 교육을 받아야 합니다. 개발자에게 안전한 방식으로 개발 언어 및 런타임 환경에 대한 통찰력을 제공하면 더 나은 코딩 방법을 지원하고 최종 웹 애플리케이션의 버그를 줄일 수 있습니다. 설계 프로세스에 보안을 통합함으로써 얻을 수 있는 또 다른 효율성 이점은 요구 사항 및 설계 중에 오용 시나리오를 설정할 수 있는 능력입니다. 테스트 및 수신 단계에서 이를 수행하면 시간이 절약되고 병목 현상을 제거하는 데 도움이 됩니다.

　통합 종합 테스트의 이점

　소프트웨어 테스트의 통합 종합 분석 방법은 효율성을 크게 향상시킬 수 있습니다. 통합 개발 환경을 위한 특정 플러그인은 사용자 코드에서 코딩 오류를 감지하면 코더에게 경고합니다. "화이트 박스" 테스트라고도 알려진 정적 분석은 최종 제품으로 조립되기 전에 개발자와 감사자가 다양한 모듈에서 사용하는 기술입니다. 정적 분석은 코드 수준에서 애플리케이션에 대한 내부자의 시각을 제공합니다. 정적 분석은 구문 오류와 코드 수준 결함을 찾는 데 효과적이지만 결함으로 인해 악용 가능한 취약점이 발생하는지 여부를 판단하는 데는 적합하지 않습니다.

　 애플리케이션이 공격에 취약한지 확인하는 데에는 동적 분석과 수동 침투 테스트가 효과적입니다. '블랙박스 테스트'라고도 하며, 주로 외부인이 애플리케이션을 검사하고 분석하는 방식을 보여주며, 공격자가 취약점을 악용하기 쉬운지 알아보기 위해 프로덕션에 투입된 애플리케이션을 심층적으로 검사할 수 있습니다. 그러나 동적 테스트 기술은 소프트웨어 개발의 후반 단계, 생성 후 단계에서만 사용할 수 있습니다. 동적 테스트의 또 다른 한계는 취약점을 일으키는 코드에서 코드 소스를 찾기가 어렵다는 것입니다.

　그래서 "회색 상자"에서 정적 및 동적 테스트를 결합하거나 하이브리드 테스트를 위한 결합 접근 방식을 취하는 것이 중요합니다. 코드 수준 내부 검사 결과를 동적 외부 검사와 결합하면 두 기술의 장점을 모두 활용할 수 있습니다. 정적 및 동적 평가 도구를 사용하면 관리자와 개발자는 애플리케이션, 모듈, 취약점의 우선 순위를 정하고 가장 큰 영향을 미치는 문제를 먼저 해결할 수 있습니다. 결합된 분석 접근 방식의 또 다른 이점은 동적 테스트를 통해 식별된 취약점을 정적 도구를 사용하여 특정 라인이나 코드 블록으로 추적할 수 있다는 것입니다. 이를 통해 테스트 팀과 개발 팀 간의 협업 커뮤니케이션이 촉진되고 보안 및 테스트 전문가가 개발자에게 구체적이고 실행 가능한 문제 해결 지침을 더 쉽게 제공할 수 있습니다.

　소프트웨어 수명주기에 보안 구축: 실용적인 접근 방식

　보안 구축에는 사람, 프로세스, 기술 및 방법이 필요합니다. 웹 애플리케이션 보안을 강화하는 프로세스를 자동화하는 데 도움이 되는 수많은 도구가 있지만 웹 애플리케이션을 생성하고 테스트하기 위한 적절한 프로세스와 숙련된 인력 없이는 어떤 도구도 실제로 효과적이지 않습니다.

　이 프로세스에는 공식적인 소프트웨어 개발 주기와 공개 전략이 포함되어야 합니다. 또한 모든 개발자의 역할을 설정하고 검사 및 감독 책임을 할당하는 것이 중요합니다. 모든 단계에서 위험 관리를 해결할 수 있도록 소프트웨어 개발 주기의 모든 단계에서 보안과 비즈니스가 표현되어야 합니다.

전체 소프트웨어 개발 주기에서 유익하고 영원한 주제는 교육입니다. 교육은 개발자에게 중요하며 웹 애플리케이션 개발과 관련된 모든 사람에게 도움이 됩니다. 보안 인식은 하향식과 상향식 모두 필요하기 때문입니다. 웹 애플리케이션 취약성이 비즈니스에 어떤 영향을 미칠 수 있는지 관리자를 교육하는 것의 중요성을 과소평가하지 마십시오. 웹 애플리케이션이 CSRF(교차 사이트 요청 위조)에 취약하다는 사실을 경영진에게 알리는 것은 혼란스러울 수 있지만, 소프트웨어 버그가 어떻게 고객 데이터 노출로 이어질 수 있는지 보여주면 경영진이 보안의 실제 결과를 인식하는 데 도움이 될 수 있습니다. 웹 애플리케이션. 다양한 비용 절감 가능성을 설명하기 위해 구체적인 사례와 지표를 준비해야 합니다. 예를 들어 개발자 교육 및 IDE용 정적 분석 플러그인에 투자하면 소프트웨어 애플리케이션이 코드를 검사하기 전에 데이터 유출 원인을 방지할 수 있음을 입증할 수 있습니다.

감사자와 평가자는 일반적인 코딩 오류에 대해 배우고, 그 결과를 평가하고, 백엔드 지원 시스템, 기존 보안 제어, 웹 애플리케이션 환경의 일부인 서비스 또는 애플리케이션을 포함한 웹 애플리케이션 "생태계"와 상호 작용할 수 있습니다. . ) 관련 종속성. 테스터와 품질 평가 전문가는 오용 시나리오와 표준 적용과의 차이점을 잘 알고 있어야 하며, 안전 테스트 결과를 해석하고 필요에 따라 결과의 우선순위를 지정할 수 있어야 합니다.

　 보안 및 위험 관리를 구현하는 동시에 효율성을 높일 수 있는 기회가 있는 소프트웨어 개발 주기의 특정 단계에 집중하세요.

　Requirements

　 웹 애플리케이션 디자이너는 기능 및 비즈니스 요구 사항 정의에 매우 익숙하지만 보안 요구 사항 정의 방법을 이해하지 못할 수도 있습니다. 이 시점에서 전체 팀은 최종 웹 애플리케이션에 어떤 보안 제어가 중요한지 결정하기 위해 협력해야 합니다.

　요구사항 단계에 보안을 통합하는 단계

　1. 회사 정책, 규정 준수 및 규제 요구 사항을 기반으로 보안 요구 사항을 논의하고 정의합니다.

　2. 보안 및 감사 팀은 웹 애플리케이션의 비즈니스 요구 사항과 기능을 평가하고 테스트 및 승인 중에 오용 사례(오용 시나리오) 개발을 시작해야 합니다.

　이점은 두 가지입니다. 하나는 보안이나 위반 문제를 사전에 제거하거나 줄이는 것이고, 다른 하나는 배포 시간을 단축하는 것입니다.

　아키텍처 및 디자인

웹 애플리케이션의 아키텍처와 디자인이 정의되었으므로 다음 단계는 보안 문제를 평가하는 것입니다. 이 단계에서는 비용이 많이 들고 해결하기 어려운 안전 문제가 가장 해결 가능한 시점에 해결될 수 있습니다. 비용이 많이 드는 실수를 방지하려면 성능과 보안 관점에서 프로그램 아키텍처를 평가해야 합니다. 개발자에게 어떤 보안 제어가 포함되어야 하는지, 애플리케이션 구성 요소가 전체 웹 애플리케이션과 상호 작용하는 방법을 보여주기 위해 상세한 디자인 사양이 컴파일되었습니다.

　보안을 아키텍처 및 설계 단계에 통합하는 단계

　1. 제안된 아키텍처 및 배포 환경에 대한 위험 평가를 수행하여 설계가 위험을 초래하는지 확인합니다.

　　2. 애플리케이션이 원래 시스템과 상호 작용할 때 보안 영향 및 위험은 물론 다양한 구성 요소, 계층 또는 시스템 간의 데이터 흐름에 대한 보안 문제를 평가합니다.

　　3. 구현 또는 배포 단계에서 해결해야 하는 특정 노출 문제(예: 애플리케이션 배포 방법 및 위치에 따라 달라지는 취약점)에 대해 설명합니다.

　　4. 매시업, SOA 및 파트너 서비스와의 상호 작용으로 인해 발생하는 종속성과 취약성을 고려합니다. 보안 테스트 계획 및 오용 시나리오를 식별하기 위해 최종 설계를 보안 및 감사에 전달합니다.

　이점은 5가지 측면에 반영됩니다:

　1. 위험 평가 분석 프로세스와 재사용 가능한 위험 평가 모델은 신중하게 조정될 수 있습니다.

　　2. 아키텍처 환경이나 배포 환경으로 인한 위험을 조기에 식별할 수 있습니다.

　 3. 재사용 가능한 오용 사례는 테스트 단계에서 시간을 절약할 수 있습니다.

　　4. 특정 설계 취약점을 줄입니다.

　5. 필요한 경우 위험을 초래하는 아키텍처 제약 조건을 조정하거나 변경할 수 있습니다. 위험을 완전히 제거할 수 없는 경우 보상 제어를 사용하여 위험 완화 전략을 정의할 수도 있습니다.

　코드 실행 및 컴파일

개발자는 코드 작성을 시작할 때 완전한 위험 평가 설계 세트와 보안 제어에 대한 명확한 지침을 보유하거나 승인된 서비스를 통해 이러한 보안 제어를 사용해야 합니다. IDE에 통합된 자동화된 정적 코드 도구는 개발자에게 코드를 작성하는 동안 검사 및 지침을 제공할 수 있습니다. 또한 자동화된 도구를 사용하여 컴파일 중에 정책 템플릿에 대한 코드 위반을 확인하고 코드 수준 보안 문제에 대한 통찰력을 제공할 수 있습니다.

　코드 실행 및 컴파일 단계에 보안을 통합하는 단계

　1. 통합 개발 환경과 통합할 수 있는 정적 소스 코드 검사 도구를 설치합니다.

　 2. 선택적으로 개발자는 독립적인 코딩 도구를 사용하여 코드를 제공하기 전에 자동화된 코드 검사를 수행할 수 있습니다.

　　3. 보안 및 감사팀은 코드 모듈을 무작위로 검사하여 규정 준수 요구 사항을 준수하는지 확인하고 자동 또는 수동 코드 검사를 사용하여 컴파일 전에 보안 위험을 확인합니다.

　4. 컴파일 프로세스 중에 자동 정적 코드 스캔을 수행하여 보안 문제 및 정책 준수 여부를 찾습니다.

　5. 도구를 사용하여 개발자의 코딩 오류를 추적하고 설명 피드백과 이로 인해 발생하는 보안 위험에 대한 이유를 제공합니다.

　다음과 같은 이점이 있습니다:

　1. 더 깨끗하거나 버그가 적은 코드를 품질 평가자에게 제출할 수 있습니다.

　 2. 개발자는 시간이 지남에 따라 보안 코딩 기능을 향상시킬 수 있습니다.

　 3. 재사용 가능한 전략은 위험 분석의 정확성을 높일 수 있습니다.

　　4. 테스트 단계에서 발견되는 코딩 오류나 취약점이 줄어들어 개발 주기가 단축됩니다.

　품질 평가/테스트

애플리케이션 테스트를 위한 특정 보안 도구는 전체 애플리케이션을 평가할 수 있는 독립형 솔루션 및 서비스부터 테스트 및 검증을 제공하는 완전히 통합된 제품군에 이르기까지 교육부터 구현까지 여러 단계에서 지원됩니다. 통합 솔루션은 반복 가능한 웹 애플리케이션 보안 주기에서 성숙도를 입증한 기업에 다단계 지원을 제공합니다. 통합 제품군은 프로세스의 여러 지점에서 구현될 수 있으며 지속적인 개선을 위한 지표와 피드백을 제공합니다.

　그렇다면 품질 평가 및 테스트 단계에서 보안을 통합하고 보안을 향상시키기 위해 어떤 조치를 취해야 할까요?

　1. 특정 리소스에서 가장 중요한 문제를 찾는 데 집중하세요.

　　2. 기존 교정 제어(예: 방화벽 및 IPS)를 포함하는 애플리케이션 아키텍처 내에서 이러한 테스트 결과를 검증합니다.

　3. 보안 및 비즈니스 요구 사항에 따라 발견된 취약점의 우선순위를 지정합니다.

　　4. 의존하는 코드 줄이나 API, 서비스, 라이브러리 등에 대한 복구를 제안합니다.

　장점도 분명합니다. 1. 애플리케이션 개발자가 서로 더 잘 소통할 수 있습니다. 2. 타당성이 떨어집니다. 3. 수리주기가 빨라집니다.

　배포/생산에 투입

　 웹 애플리케이션 보안은 애플리케이션 배포 단계에서 끝나지 않습니다. 웹 애플리케이션이 프로덕션에 들어가면 데이터와 서비스가 보호되는지 확인하기 위해 추가 테스트와 모니터링을 구현해야 합니다. 실제 웹 애플리케이션의 자동화된 보안 모니터링은 애플리케이션이 예상대로 실행되고 위험을 초래할 수 있는 정보를 유출하지 않도록 보장합니다. 모니터링은 내부에서 수행하거나 24시간 내내 애플리케이션을 모니터링할 수 있는 외부 공급업체에 아웃소싱할 수 있습니다.

배포 및 생산 단계에서 보안을 통합하고 개선하는 단계:

　1. 오용을 모니터링하는 목적은 테스트에서 소위 "악용할 수 없는 취약점"이 생산 후에 실제로 악용되지 않는지 확인하는 것입니다.

　2. 데이터가 잘못 사용, 전송 또는 저장된 모든 위치를 찾기 위해 데이터 유출을 모니터링합니다.

　3. 배포 전 위험 평가를 프로덕션 후 노출 범위와 비교하고 테스트 팀에 피드백을 제공합니다.

　　4. 웹 애플리케이션 방화벽, IPS 또는 기타 수정 조치를 구현하여 코드 수정 전 노출을 완화하거나 새로운 보안 규정을 준수합니다.

　이점은 다음과 같습니다.

　1. 성공적으로 구현할 수 있는 익스플로잇에 대한 지식 기반을 개선하여 정적 및 동적 테스트 중 검색 효율성을 향상시킵니다.

　　2. 애플리케이션 오용을 발견하고 방지합니다.

　　3. 동적 테스트와 프로덕션의 애플리케이션 제어(예: 웹 애플리케이션 방화벽 또는 IPS) 간의 더 나은 통합을 달성합니다.

　4. 코드를 다시 작성하기 전에 규정 준수 요구 사항을 충족하세요.

　5. 피드백 메커니즘을 사용하여 지속적인 개선을 달성합니다.

　요약

　웹 애플리케이션을 보호한다고 해서 반드시 개발 주기가 연장되는 것은 아닙니다. 모든 개발자를 위한 좋은 교육과 명확하고 반복 가능한 빌드 프로세스를 통해 조직은 효율적이고 협업적인 방식으로 개발 프로세스에 보안과 위험을 통합할 수 있습니다.

웹 애플리케이션 제공 주기에 보안을 구축하려면 사람, 프로세스 및 기술을 통합하는 협업 접근 방식이 필요합니다. 웹 애플리케이션 보안 도구와 제품군은 프로세스를 개선하는 데 도움이 될 수 있지만 만병통치약은 아닙니다. 최대한의 이점을 얻으려면 전체 개발 주기를 이해하고 개발 프로세스의 여러 단계에서 지원을 제공할 수 있는 도구를 갖춘 웹 애플리케이션 보안 도구 공급업체를 선택하는 것을 고려해야 합니다.

위 내용은 웹 애플리케이션 보안을 보장하는 방법을 알려주세요.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!