Google은 흑인 공동체를 위한 인종적 평등을 추구하기 위해 노력하고 있습니다. 자세히 알아보기

Firebase 보안 체크리스트

Firebase 리소스와 사용자 데이터를 안전하게 유지하려면 다음 가이드라인을 따르세요. 모든 항목이 요구 사항에 반드시 적용되는 것은 아니지만 앱을 개발할 때 염두에 두십시오.

악의적 인 트래픽을 피하십시오

백엔드 서비스에 대한 모니터링 및 알림 설정

서비스 거부(DOS) 공격과 같은 악의적인 트래픽을 감지하려면 Cloud Firestore , 실시간 데이터베이스 , Cloud Storage호스팅 에 대한 모니터링 및 알림을 설정하세요.

애플리케이션에 대한 공격이 의심되는 경우 가능한 한 빨리 지원에 연락하여 무슨 일이 일어나고 있는지 알려주십시오.

앱 확인 활성화

앱만 백엔드 서비스에 액세스할 수 있도록 하려면 지원하는 모든 서비스에 대해 앱 확인 을 활성화하십시오.

일반 트래픽에 맞게 확장하도록 Cloud Functions 구성

Cloud Functions는 앱의 요구 사항에 맞게 자동으로 확장되지만 공격이 발생할 경우 큰 비용이 발생할 수 있습니다. 이를 방지하기 위해 앱의 일반 트래픽을 기반으로 함수 의 동시 인스턴스 수를 제한 할 수 있습니다.

한도에 거의 도달했을 때 알림을 받도록 알림 설정

서비스에 요청 스파이크가 있는 경우 할당량이 시작되어 애플리케이션에 대한 트래픽을 자동으로 제한하는 경우가 많습니다. 사용량 및 청구 대시보드 를 모니터링해야 하지만 리소스 사용량이 예상을 초과할 때 알림을 받도록 프로젝트에 대한 예산 알림을 설정할 수도 있습니다.

자가 DOS 방지: 에뮬레이터를 사용하여 로컬에서 기능 테스트

Cloud Functions를 개발하는 동안 실수로 스스로 DOS를 수행하기 쉽습니다. 예를 들어, 무한 트리거 쓰기 루프를 생성하는 것입니다. Firebase 에뮬레이터 제품군 으로 개발을 수행하면 이러한 실수가 라이브 서비스에 영향을 미치는 것을 방지할 수 있습니다.

(그리고 실수로 직접 DOS를 수행하는 경우 index.js 에서 함수를 제거한 다음 firebase deploy --only functions 를 실행하여 함수를 배포 취소합니다.)

실시간 응답이 덜 중요한 곳에서는 구조가 방어적으로 기능합니다.

함수의 결과를 실시간으로 표시할 필요가 없는 경우 결과를 일괄 처리하여 남용 트래픽을 완화할 수 있습니다. 결과를 Pub/Sub 주제에 게시하고 예약된 함수 를 사용하여 정기적으로 결과를 처리합니다. .

API 키 이해

Firebase 서비스용 API 키는 비밀이 아닙니다.

Firebase는 Firebase 서비스에 대한 앱의 Firebase 프로젝트를 식별하는 데만 API 키를 사용하며 Firebase 보안 규칙 을 사용하여 수행되는 데이터베이스 또는 Cloud Storage 데이터에 대한 액세스를 제어하지 않습니다. 이러한 이유로 Firebase 서비스용 API 키를 비밀로 취급할 필요가 없으며 클라이언트 코드에 안전하게 임베드할 수 있습니다. Firebase용 API 키에 대해 자세히 알아보세요.

API 키 범위 설정

API 키를 사용하여 요청을 스푸핑하려는 공격자에 대한 추가 억제 수단 으로 앱 클라이언트 범위의 API 키를 생성할 수 있습니다.

FCM 서버 키를 비밀로 유지

Firebase 서비스용 API 키와 달리 FCM 서버 키( 기존 FCM HTTP API 에서 사용) 민감하므로 비밀로 유지해야 합니다.

서비스 계정 키를 비밀로 유지

또한 Firebase 서비스용 API 키와 달리 서비스 계정 비공개 키( Admin SDK 에서 사용) 민감하므로 비밀로 유지해야 합니다.

보안 규칙

프로덕션 또는 잠금 모드에서 규칙 초기화

Cloud Firestore, 실시간 데이터베이스 및 Cloud Storage를 설정할 때 기본적으로 모든 액세스를 거부하도록 보안 규칙을 초기화하고 앱을 개발할 때 특정 리소스에 대한 액세스 권한을 부여하는 규칙을 추가하십시오.

Cloud Firestore(프로덕션 모드) 및 실시간 데이터베이스(잠금 모드)의 새 인스턴스에 대한 기본 설정 중 하나입니다. 새 데이터베이스 인스턴스를 설정할 때 이 옵션을 선택하십시오.

Cloud Storage의 경우 다음과 같은 보안 규칙 구성으로 시작합니다.

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

보안 규칙은 스키마입니다. 문서를 추가할 때 규칙 추가

일종의 사전 출시 작업으로 앱을 작성한 후 보안 규칙을 작성하지 마십시오. 대신, 앱을 작성할 때 보안 규칙을 작성하여 데이터베이스 스키마처럼 처리하십시오. 새 문서 유형이나 경로 구조를 사용해야 할 때마다 보안 규칙을 먼저 작성하십시오.

에뮬레이터 제품군의 단위 테스트 보안 규칙 CI에 추가

보안 규칙이 앱 개발을 따라가고 있는지 확인하려면 Firebase 에뮬레이터 제품군 으로 규칙을 단위 테스트하고 이러한 테스트를 CI 파이프라인에 추가하세요. Cloud Firestore실시간 데이터베이스 에 대한 이 가이드를 참조하세요.

입증

사용자 지정 인증: 신뢰할 수 있는(서버 측) 환경에서 JWT 생성

맞춤 시스템이든 타사 서비스이든 보안 로그인 시스템이 이미 있는 경우 기존 시스템을 사용하여 Firebase 서비스로 인증할 수 있습니다. 신뢰할 수 있는 환경에서 사용자 정의 JWT를 생성 한 다음 토큰을 사용하여 인증하는 클라이언트에 토큰을 전달합니다( iOS+ , Android , Web , Unity , C++ ).

타사 제공업체에서 사용자 지정 인증을 사용하는 예는 블로그 게시물 Okta를 사용하여 Firebase로 인증을 참조하세요.

관리형 인증: OAuth 2.0 공급자가 가장 안전합니다.

Firebase의 관리형 인증 기능을 사용하는 경우 OAuth 2.0 / OpenID Connect 제공자 옵션(Google, Facebook 등)이 가장 안전합니다. 가능한 경우 이러한 공급자 중 하나 이상을 지원해야 합니다(사용자 기반에 따라 다름).

이메일 비밀번호 인증: 무차별 대입 공격을 방지하기 위해 로그인 엔드포인트에 대한 엄격한 할당량 설정

Firebase의 관리형 이메일-비밀번호 인증 서비스를 사용하는 경우 무차별 대입 공격을 방지하기 위해 identitytoolkit.googleapis.com 엔드포인트의 기본 할당량을 강화하세요. Google Cloud Console의 API 페이지에서 수행할 수 있습니다.

다단계 인증을 위해 Cloud Identity Platform으로 업그레이드

로그인 시 보안을 강화하기 위해 Cloud Identity Platform 으로 업그레이드하여 다단계 인증 지원을 추가할 수 있습니다. 기존 Firebase 인증 코드는 업그레이드 후에도 계속 작동합니다.

익명 인증

웜 온보딩에 익명 인증만 사용

사용자가 실제로 로그인하기 전에 기본 상태를 저장하려면 익명 인증만 사용하십시오. 익명 인증은 사용자 로그인을 대체하지 않습니다.

휴대전화 분실 시 데이터를 원할 경우 사용자를 다른 로그인 방법으로 전환

사용자가 로컬 저장소를 지우거나 장치를 전환하면 익명 인증 데이터가 유지되지 않습니다. 단일 기기에서 앱을 다시 시작한 후에도 데이터를 유지해야 하는 경우 사용자를 영구 계정으로 전환합니다 .

사용자가 로그인 공급자로 전환하거나 이메일을 확인하도록 요구하는 보안 규칙 사용

누구나 프로젝트에서 익명 계정을 만들 수 있습니다. 이를 염두에 두고 특정 로그인 방법 또는 확인된 이메일 주소를 요구하는 보안 규칙 으로 모든 비공개 데이터를 보호하세요.

예를 들어:

allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;

환경경영

개발 및 준비 프로젝트 설정

개발, 스테이징, 프로덕션을 위해 별도의 Firebase 프로젝트를 설정합니다. 스테이징 프로젝트에 대해 테스트될 때까지 클라이언트 코드를 프로덕션에 병합하지 마세요.

프로덕션 데이터에 대한 팀 액세스 제한

더 큰 규모의 팀과 함께 작업하는 경우 사전 정의된 역할 또는 사용자 지정 IAM 역할을 사용하여 프로덕션 데이터에 대한 액세스를 제한하여 실수 및 위반의 결과를 완화할 수 있습니다.

팀에서 개발용 에뮬레이터 제품군을 사용하는 경우 프로덕션 프로젝트에 대한 더 넓은 액세스 권한을 부여할 필요가 없을 수 있습니다.

도서관 관리

라이브러리 철자 오류 또는 새로운 유지 관리자를 조심하십시오.

프로젝트에 라이브러리를 추가할 때 라이브러리의 이름과 유지 관리자에 세심한 주의를 기울이십시오. 설치하려는 라이브러리와 이름이 비슷한 라이브러리에 악성 코드가 포함될 수 있습니다.

변경 사항을 이해하지 않고 라이브러리를 업데이트하지 마십시오.

업그레이드하기 전에 사용하는 라이브러리의 변경 로그를 살펴보십시오. 업그레이드가 가치를 추가하는지 확인하고 유지 관리자가 여전히 신뢰할 수 있는 당사자인지 확인하십시오.

워치독 라이브러리를 개발 또는 테스트 종속성으로 설치

Snyk 와 같은 라이브러리를 사용하여 프로젝트에서 안전하지 않은 종속성을 검사합니다.

기능에 대한 모니터링을 설정합니다. 라이브러리 업데이트 후 확인

Cloud Functions 로거 SDK 를 사용하는 경우 라이브러리 업데이트로 인한 동작을 포함하여 비정상적인 동작을 모니터링하고 경고 를 받을 수 있습니다.

클라우드 기능 안전성

Cloud Function의 환경 변수에 민감한 정보를 절대 넣지 마세요.

종종 자체 호스팅 Node.js 앱에서 환경 변수를 사용하여 개인 키와 같은 민감한 정보를 포함합니다. Cloud Functions에서는 이 작업을 수행하지 마십시오 . Cloud Functions는 함수 호출 사이에 환경을 재사용하므로 민감한 정보를 환경에 저장해서는 안 됩니다.

  • 비밀이 아닌 Firebase API 키를 저장하려면 코드에 포함하기만 하면 됩니다.
  • Cloud 함수에서 Firebase Admin SDK를 사용하는 경우 서비스 계정 자격 증명을 명시적으로 제공할 필요가 없습니다. SDK가 초기화 중에 자동으로 자격 증명을 얻을 수 있기 때문입니다.
  • 서비스 계정 자격 증명이 필요한 Google 및 Google Cloud API를 호출하는 경우 Node.js용 Google Auth 라이브러리는 Cloud Functions에 자동으로 채워지는 애플리케이션 기본 자격 증명에서 이러한 자격 증명을 가져올 수 있습니다.
  • Cloud Functions에서 타사 서비스에 대한 비공개 키와 자격 증명을 사용하려면 Cloud Secret Manager 를 사용하세요.

민감한 정보 암호화

민감한 정보를 Cloud Functions에 전달하는 것을 피할 수 없다면 정보를 암호화하기 위한 고유한 사용자 지정 솔루션을 마련해야 합니다.

단순한 기능이 더 안전합니다. 복잡성이 필요한 경우 Cloud Run을 고려하세요.

Cloud Functions를 가능한 한 간단하고 이해하기 쉽게 유지하세요. 함수의 복잡성으로 인해 종종 발견하기 어려운 버그나 예기치 않은 동작이 발생할 수 있습니다.

복잡한 로직이나 환경 구성이 필요한 경우 Cloud Functions 대신 Cloud Run 사용을 고려하세요.