특정 전술을 개발하여 안전하게 치트를 방지하기 전에, Roblox 보안의 기본 원칙을 이해하는 것이 중요합니다. 안전한 게임은 적대적인 행동을 예상하는 사고방식에 기반하여 구축됩니다. 코드 한 줄을 작성하기 전에 이러한 기본 원칙을 내면화해야 합니다. 이 원칙들은 당신이 내리는 모든 아키텍처 및 디자인 결정에 영향을 미쳐야 합니다.
클라이언트를 절대 신뢰하지 마세요
이것이 기본 원칙입니다. 결단력 있는 해커는 자신의 로컬 상태와 네트워크 트래픽을 완전히 제어할 수 있습니다. 해커가 이러한 수준의 제어를 가지고 있기 때문에 클라이언트 측 집행에 의존하는 모든 보안 조치는 결국 우회될 것입니다. 이것은 Roblox의 한계가 아니라 클라이언트-서버 아키텍처의 근본적인 현실입니다. 클라이언트에서 전송되는 모든 데이터 조각이 조작되었거나, 위조되었거나, 악의적인 의도로 전송되었다고 가정하세요. 여기에는 다음과 같은 권한이 포함됩니다:
- 클라이언트에서 실행되지 않더라도 모든 복제된 LocalScript 또는 ModuleScript를 디컴파일할 수 있습니다.
- 자신의 캐릭터와 모든 고정되지 않은 부품에 대한 네트워크 소유권을 가질 수 있습니다.
- Touched 이벤트나 ProximityPrompt 활성화와 같은 클라이언트 주도 이벤트를 어떤 범위나 빈도로든 트리거할 수 있습니다.
- 자신의 플레이어 위치, 물리적 특성 또는 세계와의 상호작용을 수정할 수 있습니다.
- 첫 번째 Player 인수를 제외한 임의의 인수로 RemoteEvents 및 RemoteFunctions를 어떤 빈도로든 호출할 수 있습니다.
- 예상되는 이벤트를 발생시키지 않고 자신의 로컬 DataModel의 모든 것을 변경할 수 있습니다.
- 로컬에서 실행 중인 코드의 동작을 임의로 변경할 수 있습니다.
이 때문에 모든 중요한 논리는 서버 측에서 검증되거나 서버에서만 실행되어야 합니다. 이러한 제어의 결과는 네트워크 소유권, 이동 검증 및 물리적 착취 및 접근 제어 및 기밀성에서 자세히 설명되어 있습니다.
서버 권한
서버는 모든 시뮬레이션 상태, 규칙, 플레이어 진행 및 중요한 결정에 대한 궁극적인 진실의 출처여야 합니다. 클라이언트의 역할은 세계를 렌더링하고 사용자 입력을 서버에 전송하는 것입니다.
서버의 역할은 다음과 같습니다:
- 클라이언트로부터 입력을 수신합니다.
- 요청된 작업이 가능하고 허용되는지 검증합니다.
- 작업을 실행하고 권한 있는 상태를 업데이트합니다.
- 관련된 모든 클라이언트에 결과를 복제합니다.
예를 들어, 플레이어가 "Bloxy Cola를 사고 싶어요"라고 말하면 서버는 아이템의 실제 가격, 플레이어의 돈, 상점과의 물리적 거리를 알아야 거래를 검증하고 승인할 수 있습니다. 가능한 한 검증할 상태는 클라이언트가 아닌 서버에서만 유지되어야 합니다. 예를 들어, Bloxy Cola 거래가 승인되면 서버는 플레이어의 돈에서 Bloxy Cola의 가격을 차감해야 하지만, 서버가 항상 플레이어 캐릭터를 제어할 수 있는 것은 아닙니다.
설계에 의한 보안
게임 디자인의 처음부터 보안 고려 사항을 통합하세요. 나중에 생각나는 대로 추가하는 것이 아니라 처음부터 포함해야 합니다.
- 모든 새로운 기능에 대해 위협 모델을 작성하세요. 새로운 기능마다 다음과 같은 질문을 하세요:
- 공격자가 클라이언트를 완전히 제어할 수 있다면 어떻게 이를 악용할 수 있을까요?
- 클라이언트가 기능에 사용되는 모든 매개변수에 대해 어떤 값이든 보낼 수 있다면, 최악의 결과는 무엇일까요?
- 이 기능이 초당 1,000회 이상 사용된다면 어떻게 될까요? 최대 사용 빈도는 얼마여야 할까요?
- 해커가 이를 사용하여 다른 플레이어의 경험을 망칠 수 있을까요?
- 최악의 경우 이 기능이 사용할 수 있는 자원은 얼마나 될까요?
- 이 기능을 위해 노출해야 하는 최소한의 내부 정보나 상태는 무엇인가요?
- 책임을 조기에 분리하세요. 첫날부터 ServerScriptService에 논리와 데이터를 유지하세요. ReplicatedStorage나 Workspace와 같은 복제된 컨테이너에 두지 마세요.