소프트웨어 테스팅 노트

출처: 책 Software Testing: Testing Across the Entire Software Development Life Cycle, by G. D. Everett and R. McLeod, Jr., 2007년

8장 Structural (Non-functional) Testing, 124페이지

8.3 보안 테스팅

보안 동작 테스트(security behavior testing)를 위해 동등 클래스(equivalence classes)를 활용하는 것을 고려하자. 대부분의 보안 시스템은 최종사용자 프로세싱 제한과 관련하여 직무 역할에 따른 다양한 유형 또는 수준의 보안을 가진다. 예를 들어, 일반적인 3단계 보안 시스템에서는 1) 데이터를 보기만 하면 되는 사무원 및 기타 직원(보안수준1), 2) 데이터를 보고 업데이트해야 하는 사무관리자(보안수준2), 3) 보안수준 1의 직원과 보안수준 2의 사무관리자에게 권한을 부여 및 거부하는 보안관리자(보안수준3)가 정의된다.

이러한 보안 동작을 테스트하기 위한 단순한 접근 방식은 회사의 모든 사용자 ID/패스워드 쌍(매우 민감한 기업 정보)을 수집하고, 각 사용자 ID/패스워드 쌍을 테스트하여 해당 사용자 ID가 승인되고(authorized) 적절한 보안 접근(security access)이 되는지 확인하는 것이다. 이런 방식은 소규모 회사에서는 수백 개의 ID/패스워드 쌍을 테스트해야 할 수 있고, 대기업에서는 수천 쌍을 테스트해야 할 수도 있다. 이런 상황에 동등 클래스 분석을 적용하면 각 보안 수준에 대해 20~50개의 ID/패스워드 쌍을 선택할 수 있을 것이다. 보안 수준별 ID/패스워드의 각 동등 클래스에서 일부 유효한 ID/패스워드 쌍(긍정적 테스트)과 일부 유효하지 않은 ID/패스워드 쌍(부정적 테스트)을 선택해야 하는 점을 기억하자.

새로운 애플리케이션에 대한 보안에는 애플리케이션에서 전송하거나 수신하는 데이터의 암호화뿐만 아니라 패스워드 암호화도 포함될 수 있다. 암호화에 대한 테스팅 기법은 이 교재의 범위를 벗어난다.

ID/패스워드 조합, ID/패스워드 쌍 보안 수준, 데이터 암호화에 대한 테스트를 마친 후에도 한 가지 남아 있는 보안 우려 영역이 있다. 모든 소프트웨어 기능과 마찬가지로 보안에는 성능 가격표가 함께 따라온다. 필요할 때마다 보안 액티비티를 완료하는 데는 (0보다 큰) 일정 시간이 걸린다. 일부 소프트웨어 설계자는 사용자 세션 시작 시에만 보안 체킹을 수행하는 것을 선호한다. 다른 소프트웨어 설계자는 사용자가 호출하는 각 액티비티 전에 보안 체킹을 수행하는 것을 선호한다. 또 다른 소프트웨어 설계자는 최종사용자 세션 동안 초기 체킹과 지속적인 체킹의 조합을 사용한다. 소프트웨어 설계자가 보안 구현을 위해 어떤 접근 방식을 취하는 지와 관계없이 테스터는 보안으로 인한 애플리케이션 성능 저하를 측정할 필요가 있다. 보안이 눈에 띄는 프로세싱 오버헤드를 추가할 것으로 예상되지 않았기 때문에 보안 성능을 테스트하지 않기로 결정하였고 시스템이 "라이브"로 가기 직전에 보안을 "켜기"로 설정한 회사들을 목격한 적이 있다. 이들 회사는 새 애플리케이션이 라이브로 시작된 첫날 정오에 다음 질문에 직면했다. "프로덕션에서 애플리케이션 실행 속도를 느리게 만드는 원인을 알아낼 때까지 보안을 어떻게 비활성화할 수 있을까?"