보안에 민감한 .NET 애플리케이션에 Doconut을 추가하는 방법
8/14/2026

보안에 민감한 .NET 애플리케이션에 Doconut을 추가하는 방법

애플리케이션 소유 권한 부여, 저장 경계, 보존, 브라우저 제어 및 검증과 함께 Doconut을 사용하는 방어 심층 가이드.

Doconut 뷰어는 계약서, 청구서, 엔지니어링 도면 또는 고객 기록을 표시하는 순간부터 애플리케이션의 보안 경계의 일부가 됩니다. Doconut은 보기 레이어를 제공하지만, 주변 애플리케이션은 여전히 파일을 누가 열 수 있는지, 원본이 어디에 저장되는지, 파생 데이터가 얼마나 오래 유지되는지, 조사 목적을 위해 무엇이 기록되는지를 결정해야 합니다.

계층화된 접근 제어와 감사 추적으로 둘러싸인 보호된 문서
계층화된 접근 제어와 감사 추적으로 둘러싸인 보호된 문서

Doconut의 보안 문서 보기 모범 사례 기사에서는 서버 측 렌더링을 방어 심층 설계의 한 레이어로 설명합니다. 따라서 이 글은 Doconut 주변의 애플리케이션 책임에 초점을 맞추고 구현 세부 사항은 유지 관리되는 제품 문서로 안내합니다.


위협 모델부터 시작하기

“프라이빗”과 “보안”은 설정이 아닙니다. 제어 수단을 선택하기 전에 방지하거나 탐지해야 할 이벤트를 정의하십시오.

위험예시애플리케이션 제어
무단 접근사용자가 URL의 문서 식별자를 변경모든 요청에 대한 객체 수준 권한 부여
테넌트 교차유효한 사용자가 다른 고객의 파일을 요청권한 부여 결정에 테넌트 범위 포함
소스 노출저장 경로나 원본 파일이 직접 반환서버 제어 조회 및 렌더링 흐름
오래된 접근역할이나 사례가 변경된 후에도 링크가 사용 가능짧은 세션 수명과 권한 재검증
과도한 보존임시 입력 또는 출력이 누적관찰 가능한 결과를 가진 명시적 수명 주기 작업
민감한 로깅토큰이나 파일 위치가 로그에 나타남구조화된 마스킹 및 식별자 전용 텔레메트리

시스템 내 문서와 사용자를 기준으로 위험을 우선순위화하십시오. 공개 브로셔 라이브러리와 법적 증거 포털은 같은 뷰어를 사용한다는 이유만으로 동일한 정책을 공유해서는 안 됩니다.

Doconut의 법률 문서 검토 사용 사례는 인증된 사례, 계약, 증거 및 컴플라이언스 워크플로우 내에서 제품의 역할을 이해하는 데 유용한 참고 자료입니다. 또한 권한, 저장소, 고객 기록 및 비즈니스 규칙이 호스트 애플리케이션에 가깝게 유지된다는 아키텍처 경계를 강조합니다.

문서를 열기 전에 권한 부여하기

문서를 Doconut으로 열기 전에 인증 및 객체 수준 권한 부여를 수행하십시오. 공식 .NET 6 이상 설정 가이드에서는 뷰어 구성 및 서버 측 문서 열기 방법을 보여줍니다; 해당 제품 단계 전에 애플리케이션의 ID, 테넌트 및 문서 권한 검사를 삽입하십시오.

애플리케이션이 제공하는 모든 관련 작업(페이지, 썸네일, 검색, 주석, 변환, 다운로드, 인쇄 등)에 대해 동일한 권한 부여 규칙을 반복 적용하십시오. 버튼을 숨긴다고 해서 기본 요청이 보호되는 것은 아닙니다.

브라우저에서 파일 시스템 경로, 저장 키 또는 원격 URL을 직접 받아들이지 마십시오. 애플리케이션이 소유한 문서 ID를 서버에서 저장 위치로 해결한 뒤, 해결된 객체가 권한이 부여된 테넌트와 워크플로우에 속하는지 확인하십시오.

뷰어와 저장 정책을 분리하기

뷰어가 보존 기간을 정의해서는 안 됩니다. 각 저장 클래스와 소유자를 문서화하십시오:

  • 원본 문서 — 기본 콘텐츠 또는 기록 정책에 의해 제어됩니다.
  • 임시 작업 파일 — 처리용으로 생성되며 예약된 관찰 가능한 수명 주기로 삭제됩니다.
  • 렌더링된 페이지 또는 캐시 — 최소 유용 수명으로 제한하고 원본과 동일하게 보호합니다.
  • 내보내기 및 인쇄 준비 파일 — 사용자가 해당 권한을 가질 때만 생성됩니다.
  • 로그 및 감사 이벤트 — 식별자와 결과만 포함하고, 문서 내용이나 자격 증명은 포함하지 않습니다.

전송 중 및 저장 시 암호화는 웹 서버, 저장소 제공자, 키 관리 및 배포 설정에 따라 달라집니다. 실제 환경에서 해당 제어를 검증하고, 뷰어 라이브러리 존재만으로 추론하지 마십시오.

짧은 수명의 참조를 신중히 사용하기

짧은 수명의 참조는 재생 공격 가능 시간을 줄일 수 있지만 권한 부여를 대체하지는 못합니다. 서명된 경로나 세션 토큰을 사용하는 경우:

  1. 하나의 문서와 의도된 작업에만 바인딩합니다.
  2. 워크플로우 기반의 좁은 수명을 부여합니다.
  3. 민감한 클레임이나 저장 위치를 평문으로 두지 않도록 합니다.
  4. 특권 작업에 대해 권한을 재검증합니다.
  5. 자연 만료 시점 이전에 폐기 의미를 정의합니다.
  6. 토큰을 분석, 리퍼러, 예외 메시지 및 스크린샷에 포함하지 않습니다.

브라우저 세션이 만료되면 중립적인 메시지를 표시하고 안전한 재인증 방법을 제공하십시오. 다른 테넌트가 문서를 소유하고 있는지 여부를 노출하지 마세요.

클라이언트‑사이드 제어가 할 수 있는 것과 할 수 없는 것 이해하기

다운로드 또는 인쇄 제어를 제거하면 의도된 워크플로우를 개선할 수 있지만 기밀성을 보장하지는 못합니다. 내용을 볼 수 있는 사용자는 여전히 화면을 캡처하거나 사진을 찍거나 뷰어 외부의 브라우저 기능을 이용할 수 있습니다.

클라이언트‑사이드 제한은 사용성 및 억제 수단으로 간주하십시오. 더 강력한 제어는 서버 뒤에 원본 파일을 두고, 모든 관련 요청에 권한 부여를 적용하며, 내보내기를 제한하고, 정책에 따라 가시적인 워터마크를 사용하는 데서 나옵니다.

제품 기능을 컴플라이언스 주장으로 전환하지 말 것

규제 컴플라이언스는 목적, 데이터 카테고리, 법적 근거, 계약, 지역 처리, 보존, 사고 대응 및 조직 절차에 따라 달라집니다. 뷰어는 컴플라이언스 설계를 지원할 수 있지만 자체적으로 애플리케이션을 컴플라이언스로 만들지는 못합니다.

GDPR 평가를 위해 최소한 다음을 문서화하십시오:

  • 원본 및 파생 파일이 처리·저장되는 위치
  • 각 서비스에 대한 컨트롤러·프로세서 역할
  • 관련 서브프로세서 및 전송
  • 모든 저장 클래스와 백업 정책에 도달하는 삭제 요청 흐름
  • 로깅되는 이벤트와 로그 보존 기간
  • 접근 검토 및 사고 대응 수행 방식

프라이버시 및 법무 이해관계자가 배포에 대한 결정을 검증하도록 하십시오.

보안 헤더 및 캐시 규칙 추가하기

인증된 미리보기 경로에 대해 제한적인 Content Security Policy, 프레임 정책, MIME‑sniffing 보호 및 Referrer 정책을 평가하십시오. 미리보기가 iframe 내부에 표시되는 경우 의도된 부모 오리진을 명시하십시오.

민감도와 렌더링 경로에 따라 캐시 헤더를 선택하십시오. no-store는 일부 응답에 적합할 수 있지만 성능에 영향을 주고 이미 캡처된 콘텐츠를 지우지는 못합니다. 헤더만으로 의존하지 말고 브라우저, 프록시 및 CDN 동작을 테스트하십시오.

비밀이 아닌 결정 로깅하기

유용한 감사 이벤트 예시:

  • 사용자 및 테넌트 식별자
  • 문서 식별자
  • 요청된 작업
  • 권한 부여 결과
  • 타임스탬프 및 상관 ID
  • 보존 또는 정리 결과

원시 토큰, 쿼리 문자열, 저장 URL, 개인 데이터가 포함된 문서 이름 또는 추출된 텍스트를 로그에 남기지 마십시오. 감사 로그를 변조로부터 보호하고 필요한 팀만 접근하도록 제한하십시오.

전체 흐름 검증하기

보안 테스트에는 부정적인 경우도 포함해야 합니다:

  • 인증된 상태를 유지하면서 문서 ID를 변경
  • 다른 사용자 또는 테넌트의 미리보기 URL 재사용
  • 페이지, 썸네일, 인쇄 및 내보내기 엔드포인트를 직접 호출
  • 긴 미리보기 중 세션 만료
  • 문서가 열려 있는 동안 사용자의 권한을 제거
  • 지원되지 않거나, 과도하게 크거나, 손상되었거나, 비밀번호가 설정된 입력 제출
  • 정리 작업이 적격 데이터를 제거하고 실패를 보고하는지 확인
  • 로그, 분석 및 오류 페이지에 민감한 값이 노출되는지 검사

안정적인 경우는 자동화하고, 저장 구성, 브라우저 정책 및 뷰어 버전 변경에 대해서는 수동 검토를 유지하십시오.

결론

보안에 민감한 통합은 명확한 소유권을 가집니다. Doconut은 공식 문서에 설명된 대로 문서 보기 기능을 제공하고, 애플리케이션은 인증, 권한 부여, 저장 제어, 보존, 모니터링 및 사고 대응을 담당합니다. 이러한 책임을 명시적으로 구분하면 더 강력한 제어와 보다 정직한 프라이버시 주장을 만들 수 있습니다.