출제기준 세세항목: 인터페이스 보안 · 소프트웨어 연계 테스트
인터페이스 설계 확인으로 무엇을 만들지 분명해졌다면, 이제 그것을 실제로 동작하는 프로그램으로 만듭니다. 송신 쪽에서는 보낼 데이터를 골라 표준 형식으로 바꾸고 내보내는 기능을, 수신 쪽에서는 받은 데이터를 검사하고 자기 형식으로 바꿔 반영하는 기능을 만듭니다. 그리고 오류가 나면 정의서에 적힌 대로 재전송하고 기록을 남기도록 합니다.
구현 방식은 인터페이스 상세 설계에서 정한 방식을 따릅니다. 네트워크로 데이터를 직접 주고받는 데이터 통신 방식(웹에서는 AJAX로 JSON이나 XML을 주고받는 경우가 많음)과, 양쪽 사이에 연계 테이블을 두는 인터페이스 엔티티 방식이 대표적입니다. 각 방식의 자세한 설명과 EAI, 미들웨어 종류는 인터페이스 상세 설계를 참고하면 됩니다.
이 항목에서는 구현할 때 함께 갖춰야 하는 두 가지, 즉 오가는 데이터를 지키는 인터페이스 보안과, 만든 연결이 처음부터 끝까지 제대로 이어지는지 확인하는 소프트웨어 연계 테스트에 집중합니다.
인터페이스는 시스템의 문을 바깥으로 여는 일이라, 보안에 특히 신경 써야 합니다. 위협이 생기는 곳을 데이터가 움직이는 길을 따라 나눠 보면 정리가 쉽습니다.
첫째는 네트워크 구간입니다. 데이터가 송신 시스템을 떠나 수신 시스템에 도착하기까지 지나가는 길로, 누군가 오가는 데이터를 엿보거나(스니핑), 진짜 상대인 척 끼어들거나(스푸핑), 중간에서 내용을 바꿔치기할 수 있습니다. 둘째는 애플리케이션 영역입니다. 인터페이스 프로그램 자체에 허점이 있으면, 조작된 입력값을 보내 프로그램이 의도하지 않은 명령을 실행하게 만들 수 있습니다. 셋째는 DB 영역입니다. 송수신 데이터가 저장된 테이블이나 연계 테이블에 권한 없는 사람이 접근하거나, 민감한 정보가 암호화되지 않은 채 저장되어 있으면 유출 위험이 생깁니다.
길 위(네트워크), 문지기(애플리케이션), 창고(DB) 중 어느 한 곳만 지켜서는 부족합니다. 세 곳마다 대응 방법이 다르니 하나씩 보겠습니다.
네트워크 구간은 암호화로 지킵니다. 엿보더라도 내용을 알아볼 수 없게 만들고, 상대가 진짜인지 확인하며, 중간에 바뀌지 않았는지 검사하는 것이 목표입니다. 시험에 나오는 세 가지는 '어느 계층에서 암호화하는가'를 기준으로 구분하면 쉽습니다.
IPSec은 세 방식 가운데 가장 아래쪽인 네트워크 계층(IP 계층)에서 동작합니다. IP 패킷 단위로 보호하기 때문에 그 위에서 도는 애플리케이션은 따로 신경 쓰지 않아도 모두 보호를 받습니다. 인증을 담당하는 AH와, 암호화까지 제공하는 ESP라는 두 가지 방식이 있고, 서로 떨어진 두 사무실을 안전하게 잇는 VPN에 많이 쓰입니다.
SSL/TLS는 전송 계층(TCP) 위, 응용 계층 아래에서 동작합니다. 두 시스템이 연결을 맺을 때 서로 확인하고 암호화 방식을 정한 뒤, 그 연결로 오가는 데이터를 통째로 암호화합니다. 웹 주소가 https로 시작하는 HTTPS가 바로 HTTP를 SSL/TLS 위에 얹은 것입니다. TLS는 SSL을 이어 표준화한 것으로, 지금은 TLS를 쓰지만 관례상 둘을 묶어 부릅니다.
S-HTTP(Secure HTTP)는 응용 계층에서 동작하며, 연결 전체가 아니라 주고받는 웹 메시지 하나하나를 암호화합니다. 이름이 비슷한 HTTPS와 헷갈리기 쉬운데, HTTPS는 아래쪽 통로(연결)를 암호화하고 S-HTTP는 통로를 지나는 메시지 자체를 암호화한다는 점이 다릅니다. 실제로는 HTTPS가 널리 쓰이고 S-HTTP는 거의 쓰이지 않지만, 시험에서는 세 가지를 함께 기억해 둡니다.
애플리케이션 영역은 시큐어 코딩으로 지킵니다. 시큐어 코딩은 개발 단계에서부터 보안 취약점이 생기지 않도록 정해진 규칙에 따라 코드를 작성하는 것입니다. 인터페이스로 들어온 값은 모두 믿지 않는다는 생각으로, 길이·형식·허용 값을 검사한 뒤에만 사용합니다. 받은 값을 그대로 SQL 문장에 이어 붙이지 않고, 오류 메시지에 내부 구조를 드러내지 않으며, 상대 시스템이 약속된 상대인지 인증한 뒤에만 요청을 처리하는 것 등이 대표적인 규칙입니다. 국제 웹 보안 단체인 OWASP가 발표하는 주요 취약점 목록 같은 자료가 이런 규칙을 정할 때 참고가 됩니다.
DB 영역은 저장된 데이터를 지키는 것이 핵심입니다. 주민등록번호, 계좌번호, 비밀번호처럼 민감한 데이터는 데이터베이스에 저장할 때 암호화하고, 비밀번호는 되돌릴 수 없는 해시로 저장합니다. 암호화를 어디서 하느냐에 따라 애플리케이션 코드에서 암호화 기능을 불러 쓰는 방식(API 방식), 데이터베이스에 암호화 기능을 덧붙이는 방식(플러그인 방식, 필터 방식이라고도 함), 두 방식을 섞어 쓰는 하이브리드 방식, 데이터베이스가 저장·읽기 과정에서 자동으로 처리하는 방식(TDE) 등으로 나뉩니다. 시험에서는 API·필터(플러그인)·하이브리드의 세 가지로 묻는 경우가 많습니다.
암호화와 함께 접근 통제도 필요합니다. 연계 테이블에는 인터페이스 프로그램 계정만 필요한 권한으로 접근하게 하고, 누가 언제 어떤 데이터에 접근했는지 기록을 남깁니다. 또 데이터나 파일이 몰래 바뀌지 않았는지 주기적으로 비교해 알려 주는 무결성 검사 도구(Tripwire 등)를 함께 쓰기도 합니다.
기능을 다 만들었다면 실제로 이어 붙여 봐야 합니다. 소프트웨어 연계 테스트는 송신 시스템, 중계(연계) 서버, 수신 시스템을 실제로 연결해, 데이터가 처음부터 끝까지 정확하게 전달되는지 확인하는 테스트입니다. 각 시스템이 혼자서는 잘 돌아가도, 연결하는 순간 항목 길이나 코드값, 처리 순서가 어긋나 문제가 드러나는 일이 많기 때문입니다.
연계 테스트에서 보는 것은 크게 네 가지입니다. 보낸 데이터가 빠짐없이 도착했는가(건수), 내용이 바뀌지 않고 표준대로 변환되었는가(정합성), 정해진 시간과 주기에 맞게 오갔는가(성능·주기), 그리고 일부러 오류를 일으켰을 때 정의서대로 재전송·기록·알림이 이루어지는가(오류 처리)입니다.
연계 테스트는 보통 네 단계로 진행합니다. 먼저 연계 테스트 케이스를 작성합니다. 어떤 데이터를 넣으면 수신 쪽에 어떤 결과가 나와야 하는지 정의서와 데이터 표준을 바탕으로 적습니다. 정상 데이터뿐 아니라 필수 항목이 빠진 데이터, 매핑표에 없는 코드값, 같은 데이터의 중복 전송 같은 경우도 꼭 넣습니다.
다음으로 연계 테스트 환경을 구축합니다. 송신·수신 시스템과 중계 서버를 실제 운영과 비슷하게 연결하고, 테스트용 데이터와 계정, 네트워크 접속 허용을 준비합니다. 외부 시스템이라면 상대 쪽에도 테스트 환경이 있어야 하므로 일정을 미리 맞춰 두어야 합니다.
그다음 테스트를 수행하고, 마지막으로 결과를 검증합니다. 송신 건수와 수신 건수를 비교하고, 수신 쪽에 반영된 값이 기대한 값과 같은지 항목별로 대조하며, 로그에 남은 오류를 확인합니다. 기대와 다른 결과는 원인을 찾아 고친 뒤 다시 테스트합니다.
테스트 범위는 두 단계로 나눠 넓혀 가면 원인을 찾기 쉽습니다. 연계 단위 테스트는 송신 쪽의 데이터 추출과 변환, 수신 쪽의 데이터 반영처럼 구성 요소를 하나씩 따로 확인합니다. 연계 통합 테스트는 송신부터 수신 반영까지 전체 흐름을 한 번에 이어서 확인합니다. 단위에서 문제가 없는데 통합에서 문제가 나면, 구성 요소 사이의 이음새를 의심하면 됩니다.
택배사로 배송 요청을 보내는 인터페이스를 만들면서, 통신은 HTTPS(TLS)로만 허용하고, 택배사에서 돌아오는 응답 값은 길이와 형식을 검사한 뒤에만 데이터베이스에 반영하도록 했습니다. 받는 사람 연락처는 연계 테이블에 암호화해 저장했습니다. 네트워크, 애플리케이션, DB 세 영역을 각각 지킨 예입니다.
송신 쪽 변환과 수신 쪽 반영을 따로 테스트했을 때는 문제가 없었는데, 연계 통합 테스트에서 일부 주문이 반영되지 않았습니다. 확인해 보니 중계 서버가 이름의 공백을 지우면서 길이 검사를 통과하지 못한 것이었습니다. 이음새에서만 드러나는 문제를 찾아내는 것이 통합 테스트의 역할입니다.
테스트 케이스에 '수신 서버를 잠시 멈춘 상태에서 전송'을 넣었습니다. 정의서대로 5분 간격으로 3번 재전송한 뒤 오류 로그에 기록되고 담당자에게 알림이 가는지 확인했고, 서버를 다시 켠 뒤 누락 없이 재처리되는 것까지 검증했습니다.