このページでは、組み込みのApp Attestプロバイダーを使用して、AppleアプリでAppCheckを有効にする方法を示します。アプリチェックを有効にすると、アプリのみがプロジェクトのFirebaseリソースにアクセスできるようになります。この機能の概要を参照してください。
App Checkは、 App Attestを使用して、Firebaseサービスへのリクエストが本物のアプリからのものであることを確認します。 App Checkは現在、不正リスクの分析にAppAttestを使用していません。
独自のカスタムプロバイダーでAppCheckを使用する場合は、「カスタムAppCheckプロバイダーの実装」を参照してください。
1.Firebaseプロジェクトを設定します
App Attestを使用するには、Xcode12.5以降が必要です。
アプリを登録して、Firebaseコンソールの[アプリチェック]セクションにあるAppAttestプロバイダーにアプリチェックを使用します。
Firebase製品の適用を有効にすると、登録されたアプリのみが製品のバックエンドリソースにアクセスできるようになるため、通常はプロジェクトのすべてのアプリを登録する必要があります。
オプション：アプリ登録設定で、プロバイダーによって発行されたアプリチェックトークンのカスタム存続時間（TTL）を設定します。 TTLは30分から7日の間の任意の値に設定できます。この値を変更するときは、次のトレードオフに注意してください。
- セキュリティ：TTLを短くすると、漏洩または傍受されたトークンが攻撃者によって悪用される可能性のあるウィンドウが減少するため、セキュリティが強化されます。
- パフォーマンス：TTLが短いということは、アプリがより頻繁にアテステーションを実行することを意味します。アプリの認証プロセスは、実行されるたびにネットワークリクエストにレイテンシを追加するため、TTLが短いとアプリのパフォーマンスに影響を与える可能性があります。
- 割り当てとコスト：TTLを短くし、再認証を頻繁に行うと、割り当てがより早く使い果たされます。有料サービスの場合、コストが高くなる可能性があります。割り当てと制限を参照してください。
ほとんどのアプリでは、デフォルトのTTLである1時間が妥当です。 App Checkライブラリは、TTL期間の約半分でトークンを更新することに注意してください。
2.アプリチェックライブラリをアプリに追加します
Podfileの依存関係をプロジェクトのポッドファイルに追加します。pod 'FirebaseAppCheck'
または、代わりにSwiftPackageManagerを使用することもできます。
依存している他のFirebaseSDKの最新バージョンも使用していることを確認してください。
pod installを実行し、作成した.xcworkspaceファイルを開きます。Xcodeで、アプリにAppAttest機能を追加します。
プロジェクトの
.entitlementsファイルで、AppAttest環境をproduction環境に設定します。
3.アプリチェックを初期化します
他のFirebaseSDKを使用する前に、AppCheckを初期化する必要があります。
まず、 AppCheckProviderFactoryの実装を記述します。実装の詳細は、ユースケースによって異なります。
たとえば、iOS 14以降のユーザーしかない場合は、いつでもAppAttestProviderオブジェクトを作成できます。
迅速
注：このFirebase製品は、watchOSターゲットでは利用できません。
class YourSimpleAppCheckProviderFactory: NSObject, AppCheckProviderFactory {
func createProvider(with app: FirebaseApp) -> AppCheckProvider? {
return AppAttestProvider(app: app)
}
}Objective-C
注：このFirebase製品は、watchOSターゲットでは利用できません。
@interface YourSimpleAppCheckProviderFactory : NSObject <FIRAppCheckProviderFactory>
@end
@implementation YourSimpleAppCheckProviderFactory
- (nullable id<FIRAppCheckProvider>)createProviderWithApp:(nonnull FIRApp *)app {
return [[FIRAppAttestProvider alloc] initWithApp:app];
}
@endまたは、iOS 14以降でAppAttestProviderオブジェクトを作成し、以前のバージョンでDeviceCheckProviderにフォールバックすることもできます。
迅速
注：このFirebase製品は、watchOSターゲットでは利用できません。
class YourAppCheckProviderFactory: NSObject, AppCheckProviderFactory {
func createProvider(with app: FirebaseApp) -> AppCheckProvider? {
if #available(iOS 14.0, *) {
return AppAttestProvider(app: app)
} else {
return DeviceCheckProvider(app: app)
}
}
}Objective-C
注：このFirebase製品は、watchOSターゲットでは利用できません。
@interface YourAppCheckProviderFactory : NSObject <FIRAppCheckProviderFactory>
@end
@implementation YourAppCheckProviderFactory
- (nullable id<FIRAppCheckProvider>)createProviderWithApp:(nonnull FIRApp *)app {
if (@available(iOS 14.0, *)) {
return [[FIRAppAttestProvider alloc] initWithApp:app];
} else {
return [[FIRDeviceCheckProvider alloc] initWithApp:app];
}
}
@end
AppCheckProviderFactoryクラスを実装した後、それを使用するようにAppCheckを構成します。
迅速
注：このFirebase製品は、watchOSターゲットでは利用できません。
let providerFactory = YourAppCheckProviderFactory() AppCheck.setAppCheckProviderFactory(providerFactory) FirebaseApp.configure()
Objective-C
注：このFirebase製品は、watchOSターゲットでは利用できません。
YourAppCheckProviderFactory *providerFactory =
[[YourAppCheckProviderFactory alloc] init];
[FIRAppCheck setAppCheckProviderFactory:providerFactory];
[FIRApp configure];App Checkライブラリがアプリにインストールされたら、更新されたアプリのユーザーへの配布を開始します。
更新されたクライアントアプリは、Firebaseへのすべてのリクエストとともにアプリチェックトークンの送信を開始しますが、Firebase製品では、Firebaseコンソールの[アプリチェック]セクションで適用を有効にするまで、トークンが有効である必要はありません。詳細については、次の2つのセクションを参照してください。
5.リクエストの指標を監視する
更新されたアプリがユーザーの手に渡ったので、使用しているFirebase製品に対してアプリチェックを適用できるようになります。ただし、そうする前に、そうすることで既存の正当なユーザーを混乱させないことを確認する必要があります。
リアルタイムデータベース、Cloud Firestore、およびCloud Storage
Realtime Database、Cloud Firestore、およびCloud Storageでこの決定を行うために使用できる重要なツールは、アプリチェックリクエストの指標画面です。
商品のアプリチェックリクエストの指標を表示するには、Firebaseコンソールの[アプリチェック]セクションを開きます。例えば：
各製品のリクエストメトリックは、次の4つのカテゴリに分類されます。
確認済みのリクエストとは、有効なアプリチェックトークンを持つリクエストです。 App Checkの適用を有効にすると、このカテゴリのリクエストのみが成功します。
古いクライアントリクエストとは、AppCheckトークンが欠落しているリクエストです。これらのリクエストは、アプリチェックがアプリに含まれる前の古いバージョンのFirebaseSDKからのものである可能性があります。
不明な発信元のリクエストとは、App Checkトークンが欠落しているリクエストであり、FirebaseSDKからのものではないようです。これらは、盗まれたAPIキーを使用して行われたリクエスト、またはFirebaseSDKを使用せずに行われた偽造されたリクエストからのものである可能性があります。
無効なリクエストとは、アプリを偽装しようとしている不正なクライアントからの、またはエミュレートされた環境からの、無効なアプリチェックトークンを持つリクエストです。
アプリのこれらのカテゴリの分布は、施行を有効にすることを決定したときに通知する必要があります。ここにいくつかのガイドラインがあります：
最近のリクエストのほとんどすべてが検証済みのクライアントからのものである場合は、強制を有効にしてバックエンドリソースの保護を開始することを検討してください。
最近のリクエストの大部分が古くなっている可能性のあるクライアントからのものである場合は、ユーザーの混乱を避けるために、強制を有効にする前に、より多くのユーザーがアプリを更新するのを待つことを検討してください。リリースされたアプリにAppCheckを適用すると、AppCheckSDKと統合されていない以前のアプリバージョンが破損します。
アプリがまだ起動されていない場合は、使用中の古いクライアントがないため、すぐにAppCheckの適用を有効にする必要があります。
クラウド機能
Cloud Functionsの場合、関数のログを調べることでアプリチェックの指標を取得できます。呼び出し可能な関数を呼び出すたびに、次の例のような構造化されたログエントリが出力されます。
{
"severity": "INFO", // INFO, WARNING, or ERROR
"logging.googleapis.com/labels": {"firebase-log-type": "callable-request-verification"},
"jsonPayload": {
"message": "Callable header verifications passed.",
"verifications": {
// ...
"app": "MISSING", // VALID, INVALID, or MISSING
}
}
}
次の指標フィルターを使用してログベースのカウンター指標を作成することで、GoogleCloudConsoleでこれらの指標を分析できます。
resource.type="cloud_function" resource.labels.function_name="YOUR_CLOUD_FUNCTION" resource.labels.region="us-central1" labels.firebase-log-type="callable-request-verification"
フィールドjsonPayload.verifications.appCheckを使用してメトリックにラベルを付けます。
6.施行を有効にする
施行を有効にするには、以下の各製品の指示に従ってください。製品の施行を有効にすると、その製品に対する未確認のリクエストはすべて拒否されます。
リアルタイムデータベース、Cloud Firestore、およびCloud Storage
Realtime Database、Cloud Firestore（iOSおよびAndroid）、およびCloudStorageの適用を有効にするには：
Firebaseコンソールの[アプリチェック]セクションを開きます。
施行を有効にする製品のメトリックビューを展開します。
[強制]をクリックして、選択を確認します。
強制を有効にしてから有効になるまで、最大15分かかる場合があることに注意してください。
クラウド機能
CloudFunctionsのアプリチェックの実施を有効にするを参照してください。
次のステップ
アプリをAppCheckに登録した後、開発中のシミュレーターなど、App Checkが通常は有効と分類されない環境で、または継続的インテグレーション（CI）環境からアプリを実行する場合は、次のことができます。実際の認証プロバイダーの代わりにAppCheckデバッグプロバイダーを使用するアプリのデバッグビルドを作成します。
Appleプラットフォームのデバッグプロバイダーでのアプリチェックの使用を参照してください。