情報漏洩のニュースが続く今、自作アプリのセキュリティで私が守っていること
こんにちは、YAAC税理士事務所の山田です。
ここ最近、情報漏洩のニュースを本当によく目にするようになりました。
弊事務所は、顧問先に使っていただくツールやアプリケーションを、自分たちで開発しています。
だからこそ、情報漏洩とセキュリティのリスクは、かなりシビアに管理しています。
とはいえ、私はエンジニアでもプログラマーでもありません。
独学で、AIと一緒に開発してきた人間です。
この記事では、そんな私が情報漏洩対策として何を考え、何を続けているのかを書きます。
自分でもアプリを作り始めた方や、AIを業務に入れたいけれどセキュリティが気になっている方の参考になればうれしいです。
セキュリティは「一度やればOK」ではない
最初にお伝えしたいのは、セキュリティのチェックは一度やれば終わり、ではないということです。
常に更新していくものだと思っています。
弊事務所では、定期的にセキュリティのチェックをしています。
たとえば、アプリが使っている外部の部品に、重大な弱点が見つかっていないかは、毎週自動で確かめています。
新しいアプリを公開する前や、公開範囲や権限が変わるときには、チェックリストで確認してから出します。
それから、新しいセキュリティホール（システムの弱点）の情報が入ってきたら、いち早くキャッチして、自分たちのアプリに同じリスクが潜んでいないかを確かめます。
最近も、AIで攻撃が自動化されているという記事を読んで、事務所のアプリの公開設定や権限を一通り見直しました。
ホームページも点検して、気になったところを塞いでいます。
設計のミスは、少しずつ積み重なる
アプリの開発では、ドメインやアクセス制限の設定が、作るたびに少しずつ積み重なっていきます。
一つひとつは小さな設定でも、重なるうちに、思ってもいない穴ができることがあります。
だから、コードのレビューは毎回やっています。
作ったプログラムは、作ったのとは別のAIにもセキュリティを含めてレビューさせ、指摘を確かめて直してから使います。
そして出来上がったあとも、定期的に見直しています。
作ったときに問題がなくても、あとから足した機能や設定の組み合わせで、状況は変わるからです。
誰でもアプリを作れる時代だからこそ
いまは、AIに話しかけながらアプリを作る「バイブコーディング」で、誰でも簡単にアプリを作れるようになりました。
しかも、作ったものを外部に公開することまで、できてしまいます。
私自身、この流れのおかげで、できることが一気に広がりました。
でも、誰でも作れて、誰でも公開できるからこそ、そこに対する責任をちゃんと理解したうえでやる必要があると思っています。
特に私たちは、仕事柄、守秘義務を扱う立場です。
やりたいことを早く実現するだけならできてしまう。でも、セキュリティ上の懸念があるなら、安易に着手しない。これが、いまの私の現在地です。
コードは書けなくても、「つながり」は理解する
私は、設定やコーディングを自分の手で一からできるわけではありません。
それでも、Google Cloud Run や Firebase（どちらも Google のアプリを動かすためのサービス）、Google アカウントでの認証の経路などは、基本的に自分で理解するようにしています。
見ているのは、次のようなことです。
- どこで、何が行われているのか
- どういう認証で、どことどこがつながっているのか
- そこに、どんなリスクが潜んでいるのか
そのうえで、「ここが突破されると、これが漏れてしまう。だったら、ここにはこれを置かない」というふうに、情報の配置を決めています。
たとえば、e-Tax（国税の電子申告・納税システム）と連携した仕組みでは、e-Tax にログインした状態の情報を、事務所のパソコンの外に出していません。
関与先の申告や納付の情報にまとめて届く、強い権限を持った情報だからです。
便利さより先に、「何をどこに置かないか」を決めてから作りました。
kintone をデータベースの中心に置いている理由
弊事務所では、kintone（サイボウズ社の業務アプリを作れるクラウドサービス）を、データベースの中心に置いています。
これも、情報の配置を考えた結果の一つです。
kintone は外部のサービスなので、最後は提供している会社を信用するしかありません。
ただ、これだけ多くの会社に使われているデータベースであれば、データベースそのもののセキュリティは堅牢だろうと判断しています。
もちろん、kintone に API トークン（外部のツールからアクセスするための鍵）でつないでいるツールもあります。
そこは固めておく必要がありますし、そうしたツールから届く場所には、重大な情報をなるべく置かないようにしています。
読み取りだけを許すなど、アクセスの仕方もツールごとに設計しています。
そして、もう一つ大きいのが、アクセス制限がどうなっているかを、人が画面で見て確認できることです。
データベースの設計を柔軟に組めることと、人の目で状況を確かめられること。
この2つが、私が kintone を主要なデータベースとして使っている理由です。
自分で把握できない状態にはしない
ここが、私がいちばん意識していることです。
何が起きているのか分からない。どういう設計なのか理解していない。どこにデータがあるのか分からない。
そんなアプリを作ってしまうのは、本当にNGだと思っています。
これは、AIと壁打ちしながらバイブコーディングで作るときも同じです。
作りやすさだけで考えれば、Firestore（Google のデータベース）などに置いたほうが扱いやすい場面もあるかもしれません。
それでも、顧問先の売上などの生データや、ミーティングの情報は、あえて自分が管理できる場所に置いています。
便利さより、自分で中身を確かめられることを優先する。これが、情報を預かる事務所としての考え方です。
まだ途中。だから続けていく
正直に言えば、すべてが整っているわけではありません。
手を付けている途中のところもありますし、新しい技術や攻撃の手口が出てくれば、また見直すことになります。
それでも、顧問先の大切な情報を預かる以上、ここは譲れないところです。
完璧だと言い切るのではなく、点検と見直しを続けること。
それが、自分でアプリを作る事務所として果たすべき責任だと思っています。
このセキュリティの話を切り出す元になった、納税の確認を API でワンクリックにした取り組みは、『API でワンクリック納税確認を実現』と『e-Tax API・eLTAX API 導入の手順と設計（第2弾）』に書いています。
自分の事務所でもこうした仕組みを取り入れたいという同業の方も、「AIやアプリで業務を楽にしたいけれど、情報の扱いが心配」という事業会社の方も、お気軽にご相談ください。
【お問い合わせはこちら】
https://yaac.co.jp/contact/
YAAC税理士事務所
山田 直広