社内向けに作ったアプリにも、なぜセキュリティ対策が必要なのですか？
使う人を社内に限定したつもりでも、データを取り出す入口や管理機能が外部から使えることがあります。画面のログインだけで判断せず、どこから何にアクセスできるか、誰が異常に気づき止めるかまで確認する必要があります。
『社員にしかURLを教えていない』という落とし穴
例えば、現場の点検記録を集める小さなアプリを考えてみます。社員だけにURLを配り、ログイン画面も付けた。作った担当者は社内限定のつもりでも、裏側で記録を取り出す入口が、別の条件で公開されているかもしれません。これは架空の例ですが、画面とデータの守り方を分けて考える理由になります。
APIとは、アプリ同士が情報を受け渡すための窓口です。画面にボタンが見えなくても、窓口へ直接要求を送れる場合があります。利用者を確認する仕組みと、その利用者が読んでよい記録を判定する仕組みは、そこで実際に働く必要があります。
最近の注意喚起を、自社の確認事項へ変える
JPCERT/CCは2026年10月8日の注意喚起で、国内組織で相次ぐ不正アクセスを取り上げ、従業員向けシステムやBIツールなども点検対象に挙げました。10月9日の追記を含む内容では、APIのアクセス制御や最小権限、不要な管理機能の公開停止などを勧めています。
この発表だけで、被害がAI開発に起因したとは言えません。また、すべての社内アプリが同じ問題を抱えるという意味でもありません。読み取るべきなのは、自分たちは社内用と呼んでいても、実際の公開状態と権限を確かめる必要がある、という点です。
最初に一枚、情報の通り道を書く
点検の出発点は、対策製品の購入より、自社のアプリの姿を知ることです。誰が使う画面か、どこにデータを保存するか、どのAPIを呼ぶか、管理者はどこから操作するかを、一枚に書きます。分からない箇所は空欄にせず、確認する担当を添えます。
GoogleやAzureを使っていても、企業の既存アカウントでログインできることと、必要な人だけが必要な記録を扱えることは別です。クラウドの名称を安全の根拠にせず、画面から保存先までの実際の設定を確認しましょう。
『見られる』だけでなく『見られない』を試す
先ほどの点検アプリなら、入力する社員、一覧を見る責任者、設定を変える管理者を分けます。確認するのは、社員が自分の記録を開けることに加え、担当外の記録を開けないことです。画面の表示だけでなく、裏側の窓口でも拒否される必要があります。
試験は許可を得た検証環境と架空データで行います。開発担当へ、未ログイン、一般社員、管理者、利用終了したアカウントの条件で、期待する許可・拒否を確かめてもらいます。自社の本番を無計画に調べたり、他社のシステムへ試したりする手順ではありません。
担当者がいなくても、止められるか
弱点を減らす確認と合わせて、異常時の対応を決めます。不審な大量アクセスや想定外の権限変更を誰が確認するか。接続を止めるとどの仕事に影響するか。代わりに紙や既存の表で続けられるか。技術担当だけで決められない部分です。
ログは調査に必要な記録を残しつつ、秘密情報や不要な個人情報をためない設計にします。バックアップも保存の成功表示だけで終わらせず、検証環境で戻せるかを確かめます。侵害が疑われたら、記録をむやみに消さず、情シスや対応支援者へつなぐ手順を用意します。
今週は、一つのアプリを説明できる状態に
最初の一歩は、現在使っている一つのアプリについて、利用者、保存先、外部との接続、運用担当、停止方法を書き出すことです。答えられない箇所を見つけるだけでも、次に相談する内容が具体的になります。
セキュリティ対策は、AIで作る挑戦を続けるための仕事です。JIKABI AIは、非エンジニアが業務を小さく形にし、企業の環境に合わせて公開・運用を考えられるよう支援します。個人情報を大量に扱う場合や複数企業に提供する場合は、専門担当者を交えた確認範囲を広げましょう。
出典・参考情報
情報は最終更新時点の内容です。サービスの仕様・料金・利用条件は公式情報をご確認ください。