IMS TECH TALK 「IMS Security Framework 1.1」

更新日:5月9日

2021年10月19日

IMSチーフアーキテクトのコリン・スマイス博士による寄稿(IMSグローバルのWEBサイトより)


IMS Security Framework 1.1:すべてのIMSサービスベースの仕様のセキュリティ


教育工学システムと学習リソースの間の安全なアクセスを提供することは不可欠です。 Learning Tools Interoperability / LTI Advantage、OneRoster、Comprehensive Learner Recordなど、edtechの相互運用性に関する多くのサービスベースの仕様を公開しています。安全なデータ交換、認証、および承認に対応することは、IMS Globalの仕様の重要な部分です。これらのニーズはedtechに固有のものではありませんが、社会で最も脆弱なユーザーの一部は、edtechのシステムとリソースを広範囲に使用しています。


2019年5月、IMSはSecurity Framework1.0を公開しました。このフレームワークは、IMS相互運用性仕様での使用が承認された一連のセキュリティパターンと手法を確立しました。経験によれば、セキュリティ要件は絶えず変化しており、現在機能しているソリューションは明日脆弱になる可能性があります。 2021年8月、IMSはSecurity Framework 1.1を公開しました。これには、元のバージョンを使用して得られた2年間の経験を反映した、新しいセキュリティ機能といくつかの改良が含まれています。セキュリティフレームワークは、ベストプラクティスの採用と適応に関してIMSを非常に強力な立場に置きます。それでも、今後18〜24か月でさらに改訂が必要になることはすでにわかっています。


IMSスタッフはセキュリティの専門家ではありませんが、現在675を超えるIMSメンバー組織には、ほぼすべてのテクノロジ分野の専門家がいます。そのため、私たちは彼らの専門知識を結集して、IMSセキュリティフレームワークを作成することができました。


セキュリティ上の懸念は、すべての市場セクターをカバーしています。他のいくつかの標準化団体は、非常に広く採用されているソリューションを作成しています。セキュリティフレームワークを作成する際のIMSによるアプローチは、このベストプラクティスを採用し、edtechの相互運用性の特定のニーズを満たすように適応させることです。インターネット技術特別調査委員会(IETF)のRequest For Comment(RFC)8446で定義されているように、トランスポート層セキュリティ(TLS)の使用を要求することにより、安全な通信を実現します。認証と承認の提供はより複雑です。認証とは、ユーザーが本人であることを確認することであり、承認によってユーザーはリソースにアクセスすることができます。 IMS仕様では、認証と承認をサポートしなければならない3つのシナリオがあります。


信頼関係が確立されているシステム間で交換されるWebサービスベースの情報(OneRosterが典型的な例です)


信頼関係が確立されていないシステム間のWebサービスベースの情報交換(Comprehensive Learner Recordが典型的な例です)


信頼関係が確立されている場合とされていない場合があるedtechシステム間でのユーザーの移動(LTI Advantageが典型的な例です)


そのため、2つのサードパーティ仕様が採用されています。


OpenIDFoundationからのOpenIDConnectは、認証を提供するためにOAuth2に基づいて構築されています


複数のソースからの仕様を組み合わせる場合の問題の1つは、一貫した用語を作成することです。セキュリティフレームワークでは、確立されたIMS用語を基礎として使用し、これがサードパーティの仕様で使用されている用語にどのようにマッピングされるかを注意深く説明しています。


バージョン1.1では、新しいIMS仕様の要件により、いくつかの機能が追加されています。これらの追加は次のとおりです。


OAuth 2認証コード付与ワークフローの一部としてのアクセストークン更新のサポート

アクセストークンの失効のサポート(OAuth 2クライアント資格情報の一部として[RFC7009]を使用)


アクセストークンおよび/または更新トークンの失効のサポート(OAuth 2認証コード付与ワークフローの一部として[RFC7009]を使用)


[RFC7591]および[RFC7592]を使用してOAuth 2の使用を簡素化するための動的クライアント登録のサポート


LTIに基づくシステムでのOpenIDConnect [OPENID-DCR]および[OPENID-DIS]の使用を簡素化するための動的クライアント登録のサポート


サービスプロバイダーのサービス機能の説明を取得するための、OpenAPI(JSON)ファイル形式に基づくサービスディスカバリエンドポイントおよびサービスディスカバリドキュメント(SDD)の使用の定義


いくつかのバグ修正と修正を除けば、バージョン1.1で追加された新機能はバージョン1.0と下位互換性があります。したがって、バージョン1.0から1.1への移行は、IMS仕様ごとの自然な改訂サイクルの一部として発生すると予想されます。


IMSセキュリティ委員会

IMSセキュリティ委員会には、セキュリティフレームワークを維持する責任が与えられています。この委員会は、IMS技術スタッフの一部と、IMS貢献メンバーのセキュリティおよび教育工学システムの分野の専門家を集めています。この委員会は、IMSに、最先端のセキュリティのベストプラクティスに関する認識と、組織がこれらのプラクティスをどのように適用すべきかについての洞察を提供します。セキュリティ委員会は、毎年のセキュリティ監査を実施する責任もあります。これは、セキュリティフレームワークがIMS仕様にどのように適用されているか、およびセキュリティ委員会自体の有効性を確認するための正式なレビューです。監査レポートには、短期、中期、および長期の一連の推奨事項が含まれています。これらの推奨事項は、レポートの発行後12か月以内に完了する必要があります。


IMSアーキテクトは、さまざまな仕様ワーキンググループがセキュリティフレームワークを適切に使用することを保証する責任があります。最終リリースの投票のために仕様をIMS技術諮問委員会(TAB)に提出する前に、仕様を正式なレビューのためにセキュリティ委員会に提出する必要があります。論争の的になる可能性のあるものがある場合は、候補の最終リリースプロセスの作成の一環として、仕様をセキュリティ委員会に送信して正式にレビューすることをお勧めします。


争点は何でしょうか?セキュリティフレームワークで定義されたパターンの使用は必須ではありませんが、他のアプローチを使用する場合は、明確な正当化を行う必要があります。これには、セキュリティの使用を仕様に含めないという決定がある場合も含まれます。場合によっては、仕様のセキュリティ要件がセキュリティフレームワークでカバーされていないことがあります。したがって、セキュリティフレームワークの更新は、その仕様で必要とされる新しい機能を含めるために行われます。これらの新しいパターンは、他のIMS仕様で使用できるようになります。年次セキュリティ監査は、すべてのIMS仕様がセキュリティフレームワークの最新バージョンを利用する方法を評価するための最終的なメカニズムを提供します。

閲覧数:4回

最新記事

すべて表示