kintoneの「非表示」はセキュリティではないという話

はじめに

以前、ファイル受け渡し用のkintoneアプリについて相談を受けたことがありました。

元々はファイルサーバーで運用していたのですが、

• 重要情報を含むファイルがある

• 一週間後には削除したい

• ただし、運用で管理するのが大変

• 削除漏れが発生しやすい

という課題があり、

という話になりました。

最初は「レコードアクセス権限」で考えていた

kintoneには、レコードアクセス権限があります。

しかも、

• 日付フィールド

• ステータス

• ユーザー条件

などを条件にできるため、

という設計自体は可能です。

そのため、最初は、

方向で考えていました。

しかし、業務側から別の要望が出た

ここで、実際の運用側からこういう要望がありました。

つまり、

• 過去にどういう依頼をしたか見たい

• 以前の頼み方を参考にしたい

• 申請内容自体は残しておきたい

ということです。

ここで問題になります。

レコードは見せたい。でも添付ファイルは見せたくない

つまり、今回必要だったのは、

• レコードは閲覧可能

• 依頼内容も閲覧可能

• ただし、添付ファイルだけ期限後は見せたくない

という制御でした。

しかし、kintoneのフィールドアクセス権限には、

を付けることができません。

つまり、

という制御が標準では難しいのです。

そこで出てきた妥協案

最終的に出てきたのが、

という案でした。

例えば、JavaScriptで以下のように制御します。

javascript

kintone.app.record.setFieldShown('添付ファイル', false);

これなら、

• レコード自体は残る

• 過去の依頼内容も確認できる

• 画面上では添付ファイルを見えなくできる

ため、運用要件としてはかなり現実的でした。

ただし、これは“セキュリティ”ではない

ここが今回一番重要なポイントです。

setFieldShown() は、

だけの機能です。

つまり、

• データを削除しているわけではない

• 権限を変更しているわけではない

ということです。

これはあくまで、

です。

「見えない」と「アクセスできない」は違う

例えば、

• 編集不可

• 非表示

• disabled

• CSSで隠す

これらはすべて、

です。

つまり、

「通常の画面操作では見えない」

だけです。

一方で、本当のセキュリティは、

状態を作ることです。

実務では「完全な正解」がないことも多い

今回のケースは、まさにそうでした。

例えば、

• セキュリティを優先すれば、過去参照ができなくなる

• 利便性を優先すれば、情報が残り続ける

• 運用でカバーすれば、削除漏れが発生する

という問題があります。

だから実際の現場では、

を決めながら、 現実的な落としどころを探すことになります。

今回の「期限後は非表示」という設計も、

として採用されたものでした。

最後に

kintoneは柔軟な反面、

• UI制御

• 権限制御

• セキュリティ

• 運用

を混同しやすい場面があります。

特に、

と思ってしまうのは危険です。

今回の件は、

ということを改めて考えさせられる経験でした。

次はこの記事を読みませんか？

kintone「権限チェッカー」を作った理由