Androidのリリース用keystoreファイルのパスワードをセキュアに保つ
2021.12.20
目次
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は最後の砦なので、本番環境用ビルドする際は取扱を気をつける
こちらの記事もオススメ！
書いた人はこんな人
- 「好きなことを仕事にするエンジニア集団」の（株）ライトコードです！
ライトコードは、福岡、東京、大阪の3拠点で事業展開するIT企業です。
現在は、国内を代表する大手IT企業を取引先にもち、ITシステムの受託事業が中心。
いずれも直取引で、月間PV数1億を超えるWebサービスのシステム開発・運営、インフラの構築・運用に携わっています。
システム開発依頼・お見積もりは大歓迎！
また、WEBエンジニアとモバイルエンジニアも積極採用中です！
ご応募をお待ちしております！
ITエンタメ2022.05.25COBOL開発者は「コンピューターおばあちゃん」で海軍准将!?グレース・ホッパー- ITエンタメ2022.05.23マイクロソフトの壁は穴だらけ!?デヴィッド・カトラー
- ITエンタメ2022.05.13ホーコン・ウィウム・リーが提唱したCSSの過去と未来
- ITエンタメ2022.04.28ラスムッセン兄弟が作ったグーグルマップの軌跡
関連記事
採用情報
\ あの有名サービスに参画!? /
バックエンドエンジニア
\ クリエイティブの最前線 /
フロントエンドエンジニア
\ 世界を変える…！ /
Androidエンジニア
\ みんなが使うアプリを創る /
iOSエンジニア
