セキュアなコーディングのための設計原則

ソース・コード・レベルでセキュリティを拡張するには、次の設計原則に従います:

最小限の権限

プロセスまたはユーザーには、作業の実行に必要な最小限の権限のみを付与します。ユーザー権限はロールに従って割り当てられ、その他すべての権限は拒否されます。最小保護ドメインを作成するには、プロセスまたはスレッドで必要とするときに権限を割り当て、その後権限を削除します。この原則により、攻撃およびユーザー・エラーによって発生する可能性のある損害を限度内にとどめることができます。

メカニズムの簡潔性

設計を簡潔にします。これにより、誤りが減少し、不整合が少なくなり、コードの理解とデバッグが容易になります。

完全な仲介

最初のリソースのみでなく、リソースへのアクセスを試行するたびにチェックします。たとえば、Linuxではプロセスでファイルを開いた後ではなく、開くときにアクセス権をチェックします。プロセスでファイルをオープンしている間にファイルの権限が変更された場合は、不正なアクセスにつながる可能性があります。開いているファイルがアクセスされるたびに権限をチェックできますが、実際には、アクセスが最初に取得された状況のために、このようなチェックは不要なオーバーヘッドとみなされます。

オープンな設計

コードの設計または実装を共有します。システムへの開放的なバック・ドアの安全性は、その存在を認識していることと同じなので、バック・ドアが発見される前に見つけて閉じることができるようにすることは、適切なセキュリティ・プラクティスとみなされます。この原則はパスワードや暗号化キーなどの情報には適用されません。これらの情報は、できるだけ少数の人々の間で共有することが適切です。このため、多くのセキュアな認証スキームでは、PINコードやパスワードの情報に加えて、生体認証またはハードウェア・トークンやスマート・カードなどの物理的なアーティファクトの所持にも依拠しています。

権限の分離

コードを、各モジュールで特定タスクを実行するための特定の限定された権限セットを必要とする、複数のモジュールに分割します。機密操作へのアクセス権を付与するには、複数の権限が必要になる場合があります。この原則により、職務が確実に分離され、徹底的な防御が可能になります。たとえば、権限のないメイン・スレッドは、タスクを実行するために特権スレッドを生成できます。メイン・スレッドへの攻撃に成功しても、システムへの最小限のアクセス権しか取得できません。

最小限の共通メカニズム

ユーザーとそれらのアクティビティを互いに分離します。ユーザーがプロセスやスレッド、情報チャネルを共有することは、適切なセキュリティ・プラクティスとはみなされません。

フェイルセーフ初期設定

デフォルトでは、操作へのアクセスを拒否します。必要な権限を持たないユーザーが操作を実行しようとすると、その操作は拒否され、システムは操作が開始される前と同じくらい安全です。

アカウンタビリティ

ユーザーが実行を試みたアクションごとに、ユーザーとユーザーの権限をログに記録します。ログをローテーションおよびアーカイブして、ファイル・システムが一杯にならないようにできます。

心理的な受け入れやすさ

インストール、構成、使用が簡単なセキュリティ・メカニズムを選択し、ユーザーが回避しようと考えないようにします。