Androidのリリース用keystoreファイルのパスワードをセキュアに保つ
2019.07.17
目次
keystoreファイル(.jksファイル)の重要性
今回は、Androidアプリ開発に向けての記事として、リリース用のapk（最近ではabb Androidアプリバンドル)ファイルの生成に必要な『keystoreファイル(.jksファイル)の重要性』と、『keystoreファイル生成時のパスワードをいかにセキュアに保つか』について書いてみたいと思います。
keystoreファイルは絶対に失くさないように厳重に管理しよう
まず、keystoreファイルとは、Androidアプリの最初のリリース時に生成するものです。
そして、Googleに対して「このアプリは私が責任をもって作りました」と証明するために必要なものとなります。
keystoreは、Android Studioで Build > Generate Signed APK…で作成できます
そのため、このkeystoreファイルを誤って削除したり、紛失したりするとそのAndroidアプリの更新リリースができなくなります。
筆者も、過去にkeystoreファイルを紛失したために、改めて別アプリとしてプライベートで開発しているアプリを再度「version 1.0.0からリリースしなければならない」という悲劇を経験しました。
「keystoreファイル自身はgit管理する方法」や「keystoreファイル自体を人づてにローカルで渡していく方法」など、人によりいくつか管理する方法がありますが、個人的には、keystoreファイル自体をgitで管理するのはセキュリティ上のリスクが伴うと考えます。
storePasswordとkeyPassword
keystoreファイルが流出してしまうと、applicationIdなどGoogle Playに公開されている情報から、成りすましのアプリも公開できてしまいます。
それを防ぐ最後の砦として、Androidアプリの本番リリース用パッケージをビルドする際に「storePassword」と「keyPassword」が必要となります。
storePassword、keyPasswordは共に厳重に管理される必要があります。
JenkinsなどのCI環境でアプリのビルドを行う際に、このパスワードの管理方法がよく議論されています。
それでは、いくつかのPassword管理方法をご紹介していきたいと思います！
【方法１】Password管理方法の基本形
まずは、基本となる形からいってみましょう。
app/build.gradle
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | android { // ... signingConfigs { release { storeFile file('./release.jks') storePassword 'releaseStorePassword' keyAlias 'releaseAppKeyAlias' keyPassword 'releaseKeyPassword' } } buildTypes { release { signingConfig signingConfigs.release } } } |
しかし、これではgradleファイルに平文で書かれているため、セキュリティ上のリスクが大きいです。
個人で開発している分には大丈夫ですが、チーム開発となると退職者などによる流出騒ぎのリスクに発展しかねません。
【方法２】gradle.propertiesから読み込む
gradle.properties
1 2 | RELEASE_STORE_PASSWORD=releaseStorePassword RELEASE_KEY_PASSWORD=releaseKeyPassword |
gradle.propertiesは、app/build.gradleから参照できる環境変数を格納できます。
CI環境でのビルドでは、これを利用してビルドしたりします。
app/build.gradleは、下記のようになります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | android { // ... signingConfigs { release { storeFile file('./release.jks') storePassword RELEASE_STORE_PASSWORD keyAlias 'releaseAppKeyAlias' keyPassword RELEASE_KEY_PASSWORD } } buildTypes { release { signingConfig signingConfigs.release } } } |
なお、この場合gradle.propertiesは.gitigoreに加えておく必要があります。
うっかりgitの管理下に置いてしまうと大変です。
【方法３】ビルドする端末の環境変数を利用する
個人的には、これが一番セキュアで漏洩の心配がないのでは？と考えている方法です。
~/.bash_profile
1 2 | export KSTOREPWD=releaseStorePassword export KEYPWD=releaseKeyPassword |
app/build.gradleは、下記のようにします
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | android { // ... signingConfigs { release { storeFile file('./release.jks') storePassword System.getenv("KSTOREPWD") keyAlias 'releaseAppKeyAlias' keyPassword System.getenv("KEYPWD") } } buildTypes { release { signingConfig signingConfigs.release } } } |
ポイントは、この部分です。
1 | System.getenv("KSTOREPWD") |
これにより、ビルドする端末の環境変数を利用してビルドしてくれます。
.bash_profile などであれば、Androidアプリのプロジェクトスコープ外にあるため、git管理上に上がる心配がありません。
また上述の .bash_profile をCI用ユーザーjenkinsなどに設定しておけば、ビルドをCI環境のみで行える環境作りが可能になります。
まとめ
- リリース用keystoreファイル(.jksファイル)は絶対に紛失、流出させてはならない
- keystoreファイルの管理は状況に応じて変える必要がある
- keyPassword,storePasswordは最後の砦なので、本番環境用ビルドする際は取扱を気をつける
一緒に働いてくれる仲間を募集しております！
ライトコードでは、仲間を募集しております！
当社のモットーは「好きなことを仕事にするエンジニア集団」「エンジニアによるエンジニアのための会社」。エンジニアであるあなたの「やってみたいこと」を全力で応援する会社です。
また、ライトコードは現在、急成長中！だからこそ、あなたにお任せしたいやりがいのあるお仕事は沢山あります。「コアメンバー」として活躍してくれる、あなたからのご応募をお待ちしております！
なお、ご応募の前に、「話しだけ聞いてみたい」「社内の雰囲気を知りたい」という方はこちらをご覧ください。
ライトコードでは一緒に働いていただける方を募集しております！
採用情報はこちら書いた人はこんな人
関連記事
採用情報
\ クリエイティブの最前線 /
フロントエンドエンジニア
\ 世界はお前の手の中に・・・ /
モバイルエンジニア
\ サービスの守り神！ /
インフラエンジニア
\ センスで挑め！ /
UI/UXデザイナー
\ 世界を震撼させろ！ /
WEB開発ディレクター
\ 妄想野郎カモン！ /
ゲームプランナー
\ ゲーム好き集合ー！ /
ゲームエンジニア
