Androidのリリース用keystoreファイルのパスワードをセキュアに保つ
IT技術
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管理方法をご紹介していきたいと思います!
【方法1】Password管理方法の基本形
まずは、基本となる形からいってみましょう。
app/build.gradle
1android {
2 // ...
3
4 signingConfigs {
5 release {
6 storeFile file('./release.jks')
7 storePassword 'releaseStorePassword'
8 keyAlias 'releaseAppKeyAlias'
9 keyPassword 'releaseKeyPassword'
10 }
11 }
12
13 buildTypes {
14 release {
15 signingConfig signingConfigs.release
16 }
17 }
18}
しかし、これではgradleファイルに平文で書かれているため、セキュリティ上のリスクが大きいです。
個人で開発している分には大丈夫ですが、チーム開発となると退職者などによる流出騒ぎのリスクに発展しかねません。
【方法2】gradle.propertiesから読み込む
gradle.properties
1RELEASE_STORE_PASSWORD=releaseStorePassword
2RELEASE_KEY_PASSWORD=releaseKeyPassword
gradle.propertiesは、app/build.gradleから参照できる環境変数を格納できます。
CI環境でのビルドでは、これを利用してビルドしたりします。
app/build.gradleは、下記のようになります。
1android {
2 // ...
3
4 signingConfigs {
5 release {
6 storeFile file('./release.jks')
7 storePassword RELEASE_STORE_PASSWORD
8 keyAlias 'releaseAppKeyAlias'
9 keyPassword RELEASE_KEY_PASSWORD
10 }
11 }
12
13 buildTypes {
14 release {
15 signingConfig signingConfigs.release
16 }
17 }
18}
なお、この場合gradle.propertiesは.gitigoreに加えておく必要があります。
うっかりgitの管理下に置いてしまうと大変です。
【方法3】ビルドする端末の環境変数を利用する
個人的には、これが一番セキュアで漏洩の心配がないのでは?と考えている方法です。
~/.bash_profile
1export KSTOREPWD=releaseStorePassword
2export KEYPWD=releaseKeyPassword
app/build.gradleは、下記のようにします
1android {
2 // ...
3
4 signingConfigs {
5 release {
6 storeFile file('./release.jks')
7 storePassword System.getenv("KSTOREPWD")
8 keyAlias 'releaseAppKeyAlias'
9 keyPassword System.getenv("KEYPWD")
10 }
11 }
12
13 buildTypes {
14 release {
15 signingConfig signingConfigs.release
16 }
17 }
18}
ポイントは、この部分です。
1System.getenv("KSTOREPWD")
これにより、ビルドする端末の環境変数を利用してビルドしてくれます。
.bash_profile などであれば、Androidアプリのプロジェクトスコープ外にあるため、git管理上に上がる心配がありません。
また上述の.bash_profile をCI用ユーザーjenkinsなどに設定しておけば、ビルドをCI環境のみで行える環境作りが可能になります。
まとめ
- リリース用keystoreファイル(.jksファイル)は絶対に紛失、流出させてはならない
- keystoreファイルの管理は状況に応じて変える必要がある
- keyPassword,storePasswordは最後の砦なので、本番環境用ビルドする際は取扱を気をつける
こちらの記事もオススメ!
2020.08.14スマホ技術 特集Android開発Android開発をJavaからKotlinへ変えていくためのお勉強DelegatedPropert...
2020.07.17ライトコード的「やってみた!」シリーズ「やってみた!」を集めました!(株)ライトコードが今まで作ってきた「やってみた!」記事を集めてみました!※作成日が新し...
ライトコードでは、エンジニアを積極採用中!
ライトコードでは、エンジニアを積極採用しています!社長と一杯しながらお話しする機会もご用意しております。そのほかカジュアル面談等もございますので、くわしくは採用情報をご確認ください。
採用情報へ
「好きを仕事にするエンジニア集団」の(株)ライトコードです! ライトコードは、福岡、東京、大阪、名古屋の4拠点で事業展開するIT企業です。 現在は、国内を代表する大手IT企業を取引先にもち、ITシステムの受託事業が中心。 いずれも直取引で、月間PV数1億を超えるWebサービスのシステム開発・運営、インフラの構築・運用に携わっています。 システム開発依頼・お見積もり大歓迎! また、現在「WEBエンジニア」「モバイルエンジニア」「営業」「WEBデザイナー」を積極採用中です! インターンや新卒採用も行っております。 以下よりご応募をお待ちしております! https://rightcode.co.jp/recruit