次の方法で共有

再生可能なセキュリティのコーディング

  • [アーティクル]

再生可能なセキュリティのサポートは、 高度にセキュリティ保護されたデバイスの 7 つのプロパティの 1 つです。 Azure Sphere では、デバイス上のすべてのソフトウェア (独自のアプリケーションを含む) を必要に応じて更新して、新しく検出された脆弱性に対処できることを意味します。 セキュリティは Azure Sphere が存在する理由であり、デバイスを常にセキュリティで保護することが最も重要であるというストレスをあまり頻繁に受けることはできません。 完全に安全なコードを記述することはできませんが、適切なコーディングプラクティス、新しく検出された脆弱性への対応における極端な注意、再生可能なセキュリティへのコミットメントにより、高レベルのアプリケーション コードを可能な限りセキュリティで保護することができます。 Azure Sphere アプリケーション分離モデルには、次の機能が用意されています。

  • すべてのアプリをインストールまたは実行する前に、適切に署名する必要があります。
  • アプリケーションからアクセスできるのは、アプリケーションの アプリ マニフェスト ファイルで指定されているハードウェア機能とインターネット アドレスのみです。
  • Azure Sphere SDK によって提供される API には、標準 C ライブラリのサブセットが大幅に削減されており、ユーザー アカウントやシェル アクセスなどの潜在的なセキュリティ ホールは省略されています。
  • セキュリティの問題が特定され、対処されるため、Azure Sphere セキュリティ サービスを使用して、Azure Sphere OS と顧客アプリケーションを安全に更新できます。

ただし、コード署名と攻撃面の最小化は、ここまでしか行なわれないようにします。 セキュリティで保護されたソフトウェア開発の一連のベスト プラクティスに従うと、署名するアプリケーションが可能な限り安全で安全であることを確認できます。 この記事では、Azure Sphere チームが独自の開発プラクティスで使用するツールの一部について説明します。

定期的なデプロイをスケジュールする

Azure Sphere OS と Azure Sphere SDK は、少なくとも四半期ごとに更新されます。 独自のアプリケーションの デプロイ でも同様のスケジュールを目指す必要があります。

ツールチェーンが最新の状態であることを確認する

Azure Sphere OS と SDK は、Azure Sphere ツールチェーンの大部分を形成しますが、個別に管理する他のコンポーネントがある場合があります。 これらのコンポーネントの更新については、定期的にチェックしてください。

一般的な脆弱性と露出 (CVEs) は、Azure Sphere を含むシステムのセキュリティの脆弱性を記述するために使用されるパブリック レポートです。 Azure Sphere OS の更新プログラムは定期的に CVEs に対処し、デバイスのセキュリティを維持するのに役立ちます。 可能であれば、ビルド パイプラインに CVEs のチェックを含めます。 セキュリティ更新プログラム を追跡する CISA ホームページ などのブックマーク サイト。 ツールチェーンを更新するときに、アプリケーションを再構築して再デプロイします。

コーディング標準に反映して準拠する

既知の標準に準拠するコードは、保守が容易で、レビューが容易で、テストが容易です。 C には一般公開されているコーディング標準があります。 MISRA は十分に確立されており 、CERT には C のコーディング標準もあります。これらの基本的な標準に加えて、可能な限り セキュリティ開発ライフサイクル を使用することをお勧めします。

重要なセキュリティ フラグを使用してコンパイルしていることを確認する

すべての Azure Sphere アプリは、Gnu コンパイラ コレクション (GCC) の C 言語コンパイラで構築されています。 C コンパイラ gcc は、数百の コンパイラ フラグとリンカー フラグを提供します。 Azure Sphere では、次のフラグが既定で使用されます。

  • -fstack-protector-strong: スタックスマッシュ攻撃から保護するコードを生成します。
  • pie: 位置に依存しない実行可能ファイルを生成します。
  • fPIC: 位置に依存しないコードを生成します。

フラグは -fstack-protector-all 、 よりも -fstack-protector-strong多くの保護を提供しますが、メモリ スタックの使用量が増加します。 現在の Azure Sphere ハードウェアのメモリが限られているため、 -fstack-protector-all 既定では使用されません。

Azure Sphere では、いくつかの警告フラグも使用されます。これらは、デプロイ前に修正できるコンパイル中のコードの問題を特定するために使用できます。

-Wall -Wswitch -Wempty-body -Wconversion -Wreturn-type -Wparentheses -Wno-format -Wuninitialized -Wunreachable-code -Wunused-function -Wunused-value -Wunused-variable -Wstrict-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration

セキュリティを強化するため、 -Wl,-z,now または -Wl,-z,relro 追加することもできますが、メモリ使用量が増えるので、既定では使用されません。

すべてのコードを確認する

コード レビューは、高品質のコードを確保するためのシンプルで効果的なツールです。 認定校閲者からのコード レビューなしでは、コードをチェックインしないようにすることをお勧めします。 開発者が別の開発者と共に新しいコードを説明する 1 対 1 のコード レビューは、多くの場合、元の開発者がコードの生成に関する考え方を明確にするのに役立ちます。 これにより、レビュー開発者からの入力がなくても、設計の弱点や分岐点が見つからない可能性があります。

自動テストを使用する

gtest などの自動テスト フレームワークを使用すると、プロジェクトがビルドされるたびにテスト関数のスイートを実行できます。 ベスト プラクティスは、チェックインされたすべてのコードに少なくとも 1 つのテスト関数が付属していることを確認することです。通常、より優れています。 テストの重要な種類は次のとおりです。

  • 基本的な単体テスト では、コードの各部分を実行して、設計どおりに動作していることを確認します。 テスト ケースは、 エッジでコードをテストするように設計する必要があります。通常、コーナーケースとエッジケースは、バグの実り多い原因です。
  • ファジー テスト では、関数が適切に応答するように、さまざまな型の予期しない入力を提供することで、コードを演習します。
  • 侵入テスト は、攻撃者がアプリケーションに侵入できる脆弱性を特定するのに役立ちます。

静的コード アナライザーを使用する

静的コード アナライザーは、いくつかの一般的なコードの問題を見つけるのに役立ちます。 ほとんどの場合、特定の種類のエラーに焦点を当てます。 次の無料およびオープン ソース ツールは、Azure Sphere 開発チームと一部の Azure Sphere ユーザーによって使用されるツールの 1 つです。

これらのツールの一部を実行するには、アプリケーション (またはその一部) を別のターゲット オペレーティング システムに再コンパイルすることが必要になる場合があります。

不要なコードを削除する

Azure Sphere SDK には、標準 C 開発ライブラリの削除されたバージョンが用意されています。可能な限り、独自のコードをその本質的な要素に取り除く機会を探す必要があります。 コード行が少ないほど、潜在的な脅威に対して使用可能な攻撃面は小さくなります。 到達できないコードまたは未使用のコードに関する警告を使用して、不要なコードを識別できます。