기본 키를 공개하지 않는 이유

교육 과정에서 실제 기본 키 (DB 키뿐만 아니라 모든 기본 접근 자)를 사용자에게 노출시키는 것은 잘못된 아이디어라고 들었습니다.

공격자가 자신이 아닌 내용을 읽을 수 있기 때문에 항상 보안 문제라고 생각했습니다.

이제 사용자가 어쨌든 액세스 할 수 있는지 확인해야하므로 그 뒤에 다른 이유가 있습니까?

또한 사용자가 어쨌든 데이터에 액세스해야하므로 외부 세계를위한 공개 키가 있어야합니다. 이제 공개 키는 기본 키와 같은 문제가 있습니까?

어쨌든 왜 그런지에 대한 예의 요청이 있었으므로 여기에 하나가 있습니다. 질문은이 예제에 적용되는 경우뿐만 아니라 원리 자체에 관한 것임을 명심하십시오. 다른 상황에 대한 답변은 명시 적으로 환영합니다.

활동을 처리하고, 여러 UI와 시스템 간 통신을위한 하나 이상의 자동화 된 API가있는 애플리케이션 (Web, Mobile) (예 : 회계 부서는 수행 한 작업에 따라 고객에게 청구하는 금액을 알고 싶어 함). 애플리케이션에는 여러 고객이 있으므로 데이터 분리 (논리적으로 데이터는 동일한 DB에 저장 됨)는 시스템에 있어야합니다. 각 요청은 무엇이든 유효성을 검사합니다.

액티비티는 매우 세분화되어 일부 컨테이너 오브젝트에 함께 있으므로 "태스크"라고합니다.

세 가지 사용 사례 :

1. 사용자 A는 사용자 B를 일부 작업으로 보내서 일부 활동을 수행 할 수 있도록 링크 (HTTP)를 보냅니다.
2. 사용자 B는 건물 밖으로 나가서 모바일 장치에서 작업을 열어야합니다.
3. 계정은 고객에게 작업에 대한 비용을 청구하려고하지만 응용 프로그램의 REST-API를 참조하는 일부 코드로 작업 / 활동을 자동으로로드하는 타사 계정 시스템을 사용합니다.

각 유스 케이스에는 에이전트가 태스크 및 활동에 대해 주소 지정 가능한 식별자가 있어야합니다 (또는 더 쉬워집니다).

또한 사용자가 어쨌든 데이터에 액세스해야하므로 외부 세계를위한 공개 키가 있어야합니다.

바로 그거죠. 요청해야 할 리소스를 모르는 상태 비 저장 HTTP를 가져 와서 218306URL에 질문 ID 를 노출시킵니다 . 아마도 노출 된 식별자가 예측 가능한지 궁금 할 것입니다 .

이에 대한 부정적인 답변을 들었던 유일한 장소는 "그러나 URL에서 ID를 변경할 수 있습니다!"라는 이론적 근거를 사용했습니다 . . 따라서 적절한 권한 부여를 구현하는 대신 GUID를 사용했습니다.

식별자를 예측할 수없는 상황 (자원 수집)을 상상할 수 있습니다. 공개적으로 특정 리소스를 호스팅하는 사이트가 있고 다른 사람들이 관심을 가질 수있는 사이트를 보유하고 /images/n.jpg있거나 /videos/n.mp4그 n수가 증가하는 위치 와 비슷한 위치에있는 경우 웹 사이트를 오가는 트래픽을 보는 사람은 모든 리소스를 수집 할 수 있습니다.

따라서 귀하의 질문에 직접 대답하기 위해 : 아니오, 귀하의 프로그램에만 의미가있는 식별자를 직접 "노출"하는 것은 나쁘지 않으며, 일반적으로 귀하의 프로그램이 성공적으로 운영되어야합니다.

그것을 보는 사람들이 그것을 '계정 번호'로 사용하지 않기 때문에 노출해서는 안됩니다. 예를 들어, 은행 계좌의 경우 계좌 번호가 무엇인지 알고 있습니다. 나는 그것을 기억하고, 나는 고객 서비스와 함께 전화로 사용하고, 다른 은행이 송금 할 양식, 법률 문서, 자동 지불 서비스 등을 작성할 때 사용합니다. 변경합니다. 반면에 내 계정의 기본 키는 알지 못합니다.
은행 병합, 시스템 업그레이드 및 교체 등을 통해 수년 동안 한 시스템에서 다른 시스템으로 변경 사항을 저장하는 시스템
. 기본 키는 이러한 변환 중 일부를 통해 변경 될 수 있으므로 노출, 기록 또는 기억되지 않은 경우 일반 사용자가
비즈니스 의미가없는 키는 종종 대리 키 라고 하며 종종 기본 키로 사용되는 것은 아닙니다.

btw, 내부 키 데이터베이스를 고유하게 식별하는 기본 키를 오용 및 노출하고 하나의 작업 대신 해당 시스템의 일부로 만드는 인터페이스 및 프로그램을 구축 한 경우에도 내부적으로 발생합니다. 나는 실제로 병원에서 데이터웨어 하우스 시스템을 지원하는 6 년 동안 위의 내용을 배웠습니다.

기본 키는 구현 세부 정보이므로

데이터베이스를 마이그레이션하는 경우 삽입 순서, 오래된 레코드 제거 등 몇 가지 다른 이유로 기본 키가 변경 될 수 있습니다. 데이터베이스 플랫폼 을 마이그레이션 하면 더 이상 실제 기본 키가 없을 수 있습니다. PK를 데이터 액세스 계층 위에 노출시키는 것은 누출이 발생하는 것이며, 모든 커플 링 문제가 수반됩니다.

이것은 다른 것들 (일명 배운 것)의 조합 답변입니다. 이 중 하나를 찬성하는 느낌이 든다면 적어도 다른 한 쪽을 찬성하고 실제 작업을 수행해야합니다. 더 관심이 있으시면 다른 답변을 읽으십시오.

데이터베이스 기본 키를 공개하지 말고 대신 대리 키를 사용해야합니다.

1. 사용자가 항목의 식별자를 기억 (적어도 약간)하거나 인식 할 수있게하려면 ( Graystone28s 답변 )
2. 미리 계획하고 PK가 변경 될 수있는 시스템 (데이터베이스 또는 기타)을 변경할 수 있다고 생각하는 경우. ( Telastyns 답변 )
3. 회사가 소유권을 이전하고 다른 시스템으로 데이터를 마이그레이션하더라도 사용자가 일관되게 변경되지 않는 데이터에 액세스 할 수 있도록하려면 ( Michael Durrants 답변 )
4. PK가 (시퀀스와 같이) 예측 가능한 경우 시스템에 자원 수확 문제가 발생할 수 있습니다. ( CodeCasters Answer ) 이는 시스템에 수확 할 가치가 있고 수확 관심이있는 사람 또는 누군가가 액세스 할 수있는 정보가있는 경우에만 적용됩니다.

참고 : 생성 된 키는 (kinda) 사람이 이해할 수있는 것이어야합니다 ( Sqlvogels Answer ).

시스템에 1-4가 필요하지 않은 경우 데이터베이스 PK를 공용 식별자 (여러 답변)로 사용하지 않을 이유가 없습니다. 또한 보안은 여기서 문제가되지 않습니다 (여러 답변).

내가 찾은 한 가지 이유는, 최종 사용자가 자신의 식별자가 접두사 나 그 해가 들어간 연도의 지표와 같은 것을 의미한다고 최종 사용자가 요구하는 것을 보았습니다. PK 변경은 어렵지만 대리가 훨씬 쉽습니다.

기본 키는 아마도 성능상의 이유로 데이터베이스 인덱싱을 원하는 것일 수 있으며 기술적 인 이유로 인해 예를 들어 숫자에서 길드로 변경할 수 있습니다. 새로운 기술이나 지식의 이유를 모릅니다. 당신을 안내 할 수 있습니다. 귀하의 pk는 기술 데이터 항목이며 공개 키는 최종 사용자가 사용하는 것입니다.

대부분의 응용 프로그램에서는 키를 사용자에게 노출시키는 것이 매우 중요합니다. 정보 시스템을 효과적으로 사용하려면 해당 시스템의 사용자는 일반적으로 정보를 식별하고 해당 정보를 데이터베이스 외부 세계의 정보와 연관시키는 방법이 필요합니다. 관계형 데이터베이스 용어에서 이러한 식별자는 키입니다.

잘 사용되는 디자인 패턴 중 하나는 추상화 수단으로 데이터베이스 테이블에 대한 추가 "기술적"키를 작성하는 것입니다. 예를 들어 일부 대체 키가 변경 될 수있는 안정적인 (상대적으로 변하지 않는) 키를 제공합니다. 이러한 기술 키는 일반적으로 최종 사용자에게 노출되지 않습니다. 그렇게하면 사용자 요구 사항의 의도 된 추상화가 손상되기 때문입니다. 보안과는 아무런 관련이 없습니다.

질문에 내재 된 문제 / 오해는 기본 키라 는 용어를 부적절하게 사용했기 때문 입니다. 기본 키는 여러 "후보"키 중 하나입니다 (데이터베이스 테이블에서 여러 가지 가능한 식별자). 기본 키는 다른 키와 근본적으로 다른 속성을 요구할 필요가 없으므로 기본 키에는 적용되고 다른 키에는 적용되지 않는 어설 션 및 디자인 원칙은 항상 의심스럽고 종종 잘못된 것입니다.

일반적으로 사용자에게 키를 공개해야한다면 그 키는 무엇이어야합니까? 친숙하고 간단하며 안정적으로 키를 만드십시오. 친숙 함과 단순성으로 키를 쉽게 읽고 기억할 수 있으며 데이터 입력 오류를 피할 수 있습니다. 안정성은 중요한 변경이 드물게 발생하여 잘못 식별 할 가능성을 방지하는 데 도움이됩니다.

이것은 CodeCaster의 Greystone28의 답변에 대한 의견입니다. 그것은 당신이 말하는 것의 예입니다 :

고객에게 의미가 있고 변경할 수있는 InvoiceNumber를 공개하지만, 코드에서 청구서를 고유하게 식별하는 데 사용하는 InvoiceID도 공개합니다. 사용자 키를 스토리지 키로 설정하지 않아도되며 더 자주 원하지 않습니다. 이 질문은 후자에 관한 것입니다.

앱에서 InvoiceID를 표시하는 목적은 무엇입니까?

노출함으로써 사용자가 볼 수 있다고 가정합니다. 사용자가 앱을 사용해야하는 경우에만 노출하십시오. 기술 지원이나 일부 관리 도구로 사용할 수 있습니다. 이 작업을 수행하는 몇 가지 앱으로 작업했습니다. 문제의 특정 기록을 알면 쉽게 지원을 제공 할 수 있습니다.

엔터티가 외부 세계에 노출되는 고유 식별자를 갖는 것은 완전히 정상입니다. 일부 개체의 경우 실제로 의미가있는 식별자 (예 : 송장 번호)를 찾을 수 있지만 다른 식별자의 경우 해당 식별자가 없으므로 생성해야합니다.

일관성과 가독성을 위해 시스템의 모든 엔터티가 식별자에 대해 정확히 동일한 유형과 이름을 사용하는 것이 좋습니다. 일반적으로이 식별자는 <type> getId()일부 추상 기본 클래스에서 노출됩니다 ( ).

같은 이유로 시스템의 각 서비스 (예 : 송장 서비스)는 식별자로 엔티티에 액세스하는 동일한 방법을 제공해야합니다. 일반적으로이 메소드 ( findById(<type> id))는 일반 서비스 인터페이스 또는 기본 클래스에서 상속됩니다.

이 식별자는 엔티티의 기본 키일 필요는 없지만 하나 일 수 있습니다. 키 생성 전략이 합리적으로 고유 한 식별자 (일반적으로 고유하지는 않지만 적어도 시스템 내에서)를 생성한다는 것만 보장하면됩니다.

시스템이 나중에 다른 데이터베이스로 마이그레이션되면 (기본 키를 기반으로하지 않는) 다른 전략 (기본 키를 기반으로하지 않음)을 사용하여 전략이 원본과 호환되는 한 식별자를 만드는 데 문제가되지 않습니다.

기본 키는 개발자로서 액세스하려고하는 튜플 (레코드, 행)에 대한 핸들과 같습니다. 또한 참조 무결성 (외부 키 제약 조건)에 사용되며 하나 이상의 사용 사례가있을 수도 있습니다.

기본적으로 사용자 나 해커에게 노출시키는 것은 나쁘지 않습니다. 예를 들어 기본 키를 사용하는 공격을 모르기 때문입니다.

그러나 보안에는 많은 원칙 (승인 및 승인하지 않음)이 있으며이를 준수해야합니다.

1. 임대 특전의 원칙
2. 모호함을 통한 보안

그리고 다른 원칙들도 있습니다. 그들이 본질적으로 말하는 것은 :

데이터를 공개 할 필요가 없다면 왜 하시겠습니까?