アプリやWebシステムの開発を依頼するとき、
「セキュリティは大丈夫ですか?」
「個人情報は安全に扱われますか?」
「公開したあとに不具合が大量に出ませんか?」
といった点が気になる方は多いと思います。
ただ、開発会社に「セキュリティ対策をしていますか?」と聞いても、多くの場合は「しています」という回答になります。
問題は、具体的に何をしているのかです。
micomiaでは、アプリ・Webシステムを開発する際に守る品質基準・セキュリティ基準を文書化しています。
この記事では、専門知識がない方にも分かるように、私たちが標準で行っているセキュリティ対策をご紹介します。
私たちが納品するシステムで目指している状態
細かな技術の話よりも、最初に「結果としてどうなるのか」をご説明します。
micomiaでは、原則として次のような状態を満たすことを前提に設計・開発を進めています。
他人のアカウント情報を勝手に見ることができない
ログインしていない人が直接データへアクセスしても拒否される
ボタンを何度押しても二重決済・二重登録されない
同時に操作されても在庫や残高などの数字がおかしくならない
パスワードをそのまま保存しない
個人情報を必要以上に収集しない
エラー画面から内部情報が漏れない
不要なカメラ・位置情報などの権限を要求しない
アクセスが急増してもクラウド料金が際限なく増えないよう備える
公開前にセキュリティ・品質確認を行う
納品後、他社へ引き継ぐ場合にも分かる形でソースコードを管理する
こうした対策を、一部の高額な予算のあるプロジェクトだけに付けるオプションとは考えていません。
通常のアプリ・Webシステムを作るうえで必要な品質の一部として扱っています。
1. セキュリティは、完成してから追加するものではありません
アプリのセキュリティというと、
「まずアプリを完成させて、最後にセキュリティ対策を追加する」
というイメージを持たれることがあります。
しかし実際には、それでは対応できないものが多くあります。
例えば、
ログインの仕組み
管理者と一般ユーザーの権限の違い
個人情報をどこへ保存するか
決済をどのように処理するか
誰がどのデータを閲覧できるか
といったものは、アプリの土台そのものです。
完成後に変更しようとすると、大きな作り直しになることがあります。
そのためmicomiaでは、お見積り・設計の段階から必要なセキュリティ対策を含めて考えます。
「セキュリティを外せば安くできます」という前提でのお見積りは原則行っていません。
2. 担当者の経験だけに頼らず、ルールとして管理
開発品質を担当者個人の経験だけに頼ると、
「担当者Aなら対策されていたのに、担当者Bでは抜けていた」
ということが起こります。
そのためmicomiaでは、開発時に守る内容を文書化しています。
現在は、大きく分けて次の基準を設けています。
セキュリティに関する基準
個人情報の取り扱いに関する基準
開発・テスト・納品品質に関する基準
これらは細分化されており、合計44項目を基本ルールとして管理しています。
3. ログイン・会員機能で気をつけていること
会員登録やログイン機能のあるアプリでは、画面を隠すだけでは十分ではありません。
例えば、他人のユーザーIDを指定して通信すれば、その人の情報が取得できてしまうシステムでは問題があります。
そのためmicomiaでは、画面だけではなくサーバー側でも、「この人は、このデータを見る権限があるのか」を確認する設計を基本としています。
また、プロジェクトに応じて次のような対策を行います。
一定時間操作がなければ管理画面から自動ログアウト
ログイン情報には有効期限を設定
ログイン情報を更新すると古いものを無効化
パスワードを複数回間違えた場合の一時ロック
パスワードを元に戻せない形で保存
ログイン失敗時に、登録済みメールアドレスかどうかを必要以上に表示しない
特に管理画面は、一般ユーザー以上に多くの情報を扱うため、通常画面とは分けて考えます。
4. 二重決済・二重登録を防御
アプリを使っていて、「購入ボタンを押したけれど反応しないので、もう一度押した」という経験はよくあると思います。
このときシステム側の作りが不十分だと、商品が2回購入されたり、ポイントが二重に増えるといった問題が起こります。
micomiaでは、決済・予約・在庫・残高など重要な処理について、同じ操作が複数回送られても、1回だけ処理される設計を行います。
単にボタンを押せなくするだけではなく、通信が複数回来た場合も考慮します。
また複数人が同時に操作するサービスでは、「最後に保存した人の数字で上書きされる」といった問題が起きないよう、データ更新方法も設計します。
5. 個人情報は「必要なものだけ集める」が基本
個人情報について最も安全なのは、必要のない情報を最初から持たないことです。
例えばサービスに生年月日が必要なければ、登録項目に入れない。
住所が不要なら、住所を取得しない。
これを基本としています。
そのうえで、扱う情報に応じて、下記の対応を検討します。
保存時の暗号化
通信時の暗号化
アクセスできる人の制限
バックアップの保護
ログへの個人情報出力防止
削除依頼への対応方法
氏名・住所などの重要な個人情報を保存する場合は、案件に応じて暗号化を行い、暗号化に使用する鍵もプログラムとは分けて管理します。
またmicomiaでは、原則としてマイナンバーを扱うシステムは通常案件とは分けて判断しています。
6. アプリの中にパスワードや重要な鍵を直接入れない
スマートフォンアプリは、利用者の端末にインストールされます。
そのため、「アプリの中に書いておけば見つからないだろう」という考え方は危険です。
アプリは解析される可能性があることを前提として設計する必要があります。
例えば、
データベースの重要なパスワード
管理用の秘密鍵
外部サービスの重要な認証情報
などを、アプリへ直接書き込むことは避けます。
サーバー側や専用の秘密情報管理サービスを利用し、アプリ側に置く情報を最小限にしています。
7. スマートフォンアプリでは「端末側」の安全性も確認
Webシステムと違い、スマートフォンアプリでは利用者の端末そのものも考える必要があります。
例えば、「カメラ、マイク、位置情、写真、Bluetooth、連絡先」などです。
micomiaでは、アプリに必要な権限だけを要求することを基本としています。
「将来使うかもしれないから、とりあえず位置情報も取得する」
といった設計は原則行いません。
また、
権限を拒否されてもアプリが異常終了しないか
外部ライブラリによって不要な権限が追加されていないか
アプリ内部で表示するWebページの範囲が広すぎないか
端末内に重要な情報をそのまま保存していないか
といった点も確認しています。
8. お問い合わせフォームや投稿機能も攻撃対象
攻撃というと、大企業や銀行だけが対象になるイメージがあります。
しかし実際には、「お問い合わせフォーム」、「コメント欄」、「掲示板」、「管理画面」、「ファイルアップロード」、「ログイン画面」など、一般的な機能も攻撃対象になります。
例えば入力欄へ特殊な文字列を入れることで、
管理画面上で不正な処理を実行する
データベースへ不正な命令を送る
他の利用者になりすます
本来見られないファイルを取得する
といった攻撃があります。
そのためWeb・APIを含む案件では、代表的な攻撃パターンを一覧化し、公開前に確認します。
入力内容を信用しすぎないこと、権限チェックをサーバー側でも行うことで万が一のリスクを未然に防いでいます。
9. ファイルアップロードにも制限
画像投稿やPDFアップロードのあるサービスでは、ファイルをそのまま受け取るだけでは十分ではありません。
例えば、極端に大きなファイルや想定していない形式、危険な内容を含むファイルなどが送信される可能性があります。
そのため、「ファイルサイズ」、「ファイル形式」、「保存先」、「公開範囲」を確認したうえで設計します。
また、非公開ファイルについてはURLを知っているだけで誰でも閲覧できる状態にならないよう、アクセス方法も分けます。
10. クラウド料金が突然跳ね上がらないようにします
現在のアプリやWebシステムでは、AWS・Google Cloud・Firebaseなどのクラウドサービスを利用するケースが多くあります。
クラウドは非常に便利ですが、多くの場合は「使った分だけ料金が発生する」仕組みです。
そのため設計を誤ると、アクセスが急増した際にクラウド料金まで急増する可能性があります。
micomiaでは、案件に応じて、サーバーの設計を検討します。
大規模アクセスが予想されるサービスでは、さらに追加の対策をご提案します。
11. 外部サービスを利用する場合も確認
現代のアプリは、多くの外部サービスを利用し、すべてをゼロから作るわけではありません。
こうしたサービスについても、「有名なサービスだから安全だろう」だけでは判断せず、扱う情報、権限、保存場所、利用目的を確認したうえで組み込みます。
また外部ライブラリやSDKについても、不要なものを大量に追加しないよう管理します。
12. ソースコードと変更履歴を管理
開発を外注するときに意外と重要なのが、「数年後に別の会社でも触れる状態か」という点です。
特定の担当者しか分からない状態にすると、担当者がいなくなっただけで保守が難しくなります。
micomiaでは、原則としてGitなどを利用して、ソースコードや変更履歴、バージョンを管理します。
ソースコードの納品に関しては納品条件によりますが、他社へ引き継ぐ場合にも状況を把握しやすい状態を意識して開発します。
13. 既存システムの改修では、すべてを一度に直せないこともあります
すでに運用中のアプリ・Webシステムをご相談いただくこともあります。
既存システムの場合、データベース構造、ログイン方式、使用している技術
外部サービス、現在のコード品質などによっては、今回ご紹介した基準まで一度に引き上げることが難しい場合があります。
その場合は、現状を確認して優先順位の高い対策を提案します。
14. セキュリティ対策による追加料金について
この記事でご紹介したような基本的な対策については、micomiaでは原則として標準の開発品質に含めています。
そのため、「セキュリティ対応を追加したのでオプション料金」という考え方にはしていません。
*金融系・インフラ系など大規模システムは別途ご相談ください。
15. micomiaが考える「品質」
私たちは、デザインがきれいで、予定どおり動くだけでは十分ではないと考えています。
アプリ・Webシステムは公開されてから長く使われます。
そのため、安全に使える、不具合が起きにくい、修正しやすい、他社でも引き継げる、将来的に機能を追加できるところまで含めて品質だと考えています。
また、品質を担当者個人の技術力や注意力だけに頼らず、ルール・テスト・レビューという仕組みで再現できる状態を目指しています。
16.おわりに
アプリ開発を初めて依頼される方にとって、「どこまで確認すれば良いのか分からない」というのは当然だと思います。
セキュリティや品質について専門知識を持ってから発注する必要はありません。
「会員登録がある」
「決済を入れたい」
「個人情報を扱う」
「将来的に利用者が増える予定」
といった情報を教えていただければ、必要な対策はこちらで整理します。
micomiaでは、アプリ・Webシステムの開発内容だけでなく、公開後に安全かつ継続的に運用できるところまで考えた設計をご提案しています。
ココナラ内からお気軽にご相談ください。