OutSystemsを使用したセキュアなアプリケーション構築
目次
ITプロフェッショナルの多くは、アプリケーションのセキュリティが非常に重要であることを認識しています。ただ、これを実行に移すのは簡単なことではありません。その結果、近年データ侵害の数が増加しています。開発者が何かを見落としてしまったり、前日のセキュリティ基準（最新ではない）に沿ったアプリケーションを開発したりしやすい状況にあるためです。また、開発者やインフラマネージャーは、システムをセキュアにできるチェックボックスやワンクリックボタンなどはないということも忘れがちです。
セキュリティに対するOutSystemsのコミットメント
OutSystemsでは、OutSystemsを使用して生成したアプリケーションのセキュリティを継続的に改善することに努めています。そのため、OutSystemsプラットフォームは、開発者が最小限の労力でセキュアなアプリケーションを構築できるメカニズムを備えています。
脆弱性に関するOWASP Top 10
OWASP（Open Web Application Security Project）は、無料のオープンなソフトウェアセキュリティコミュニティです。OWASP Top 10には、Webアプリケーションに見られる主な脆弱性がまとめられています。ここでは、そうした脆弱性のないアプリケーションを構築するうえで、OutSystemsがどのように役立つかを紹介します。
インジェクション攻撃（A1）
デフォルトでは、OutSystemsはコンテンツがUIとして表示される前にエスケープします。デフォルトのエスケープメカニズムを無効にする必要がある場合、OutSystemsではHTML、JavaScript、SQL、またはURLをエンコードする機能を提供し、使用状況に基づいた適切なエスケープを行うことが可能です。
また、HTML、JavaScript、およびSQLのサニタイズ機能も備えています。これらの機能によって、ユーザー入力から入り込むか計算される悪意ある可能性のあるコンテンツを、データベースへの保存前、かつWebページでのコンテンツのレンダリング前に削除できます。
さらに、OutSystemsの開発環境は設計時にコードインジェクション攻撃につながりうるアプリケーションのパターンを警告します。これにより、開発者はアプリケーションのデプロイ前に欠陥に気付くことができます。
認証およびセッション管理の不備（A2）
デフォルトでは、OutSystemsは以下のように設定されています。
- ユーザー名/ユーザーIDをユーザー識別用Cookieに含めない。
- URLでセッション識別子を送信しない。
- セッションを有効期限にタイムアウトさせる。
- パスワードを処理する際は、必ず強力な暗号化アルゴリズムを使用する。
同様に、OutSystemsはログインのたびにセッション識別子を透過的に変更し、リクエストごとにこれを検証することで、セッション固定攻撃を防ぎます。
さらに、あらゆるコンテンツがセキュアな接続経由で送信されるようにするためのメカニズムも用意しています。この機能は、個々の画面または統合エンドポイントに対して有効にすることも、アプリおよびAPIポートフォリオ全体にまで範囲を拡大して適用することもできます。管理レベルを細かく設定できるため、セキュリティを微調整し、独自のニーズに合わせてアプリケーションをモデル化できます。
デフォルトでは、すべてのモバイルアプリケーションの全画面および連携でHTTPSが有効になっています。また、OutSystemsにはアプリケーションを外部の認証プロバイダと簡単に連携させられるメカニズムが搭載されているため、最小限の労力でアプリケーションを組織のエコシステムに適合させることができます。
クロスサイトスクリプティング（A3）
XSS（クロスサイトスクリプティング）に関する問題は、インジェクションに関する問題と同様に対処できます。OutSystemsには、入力をエンコードし、サニタイズする機能があります。従来の開発とは異なり、OutSystemsのモデル駆動型アプローチではリアルタイムの分析が可能です。そのため、設計時にOutSystemsビジュアルエディタで開発者に警告を行い、アプリケーションのデプロイ前にセキュリティの問題を修正できます。
さらに、アーキテクト、オペレータ、または管理者がコンテンツのセキュリティポリシーを定義し、アプリケーションページがリソース（画像、CSS、スクリプト、メディア）を取得するドメインを指定できるようにするメカニズムもあります。この設定は、環境ごとに構成してすべてのアプリケーションに包括的に適用することも、特定のアプリケーションに定義することもできます。アプリケーションがリソースを読み込めるソースを限定することで、悪意のあるサイトからのスクリプト読み込みを要求するXSS攻撃を効果的に軽減することができます。
また、コンテンツのセキュリティポリシーを使用して、アプリケーションページのフレーム埋め込みを防止すると、クリックジャッキングを防ぐこともできます。
安全でないオブジェクトの直接参照、および機能レベルでのアクセス制御の欠落（A4、A7）(A4, A7)
これら2つは通常、アプリケーションの設計と実装に関連する問題ですが、OutSystemsを使用することで、開発者はどのユーザーにどのアプリケーションリソースへのアクセスを許可するかを、以下のように簡単に定義することができます。
- 所定の画面へのアクセスに必要なユーザーのロール、または所定のアプリケーションへのアクセス権を持つユーザーの定義
- ユーザー権限に基づいた、UI要素の無効化または非表示
- アクション実行時のユーザー権限の検証
- ユーザー権限に応じた特定のロジックの実行やデータのサブセットへのアクセス
すべてのOutSystems管理コンソールおよびAPIでは、ユーザー権限の強力な検証が義務付けられます。そのため、適切なレベルの権限を持つユーザーのみが各操作を実行できます。
セキュリティ設定のミス、および機密データの露出（A5、A6）
通常、これらの2つの問題は、アプリケーションの設計または実装に問題がある場合に発生します。OutSystemsは、プラットフォームのインストールをセキュアに実行する方法を明確かつ簡潔にシステム管理者に指示します。
生成したコードのエラー処理や例外処理を完全に行うため、機密情報がユーザーやブラウザに露出されてしまうことはありません。入念な例外処理は、暗号化、認証、認可、監査、およびロギングにも適用されます。
これと同時に、OutSystemsでは、あらゆるコンテンツをセキュアな接続経由で送信されるようにするために必要な機能を開発者に提供します。また既存の暗号化APIとの連携によって、データベースに保存されているデータの安全性も確保します。
クロスサイトリクエストフォージェリ（A8）
OutSystemsでは、Webページが指定された環境で指定されたユーザーに対して生成されるようにするためのトークンベースのメカニズムが、デフォルトで各ページに含まれています。トークンは、正当なエンドユーザーのみが持つ情報で暗号化および署名されます。POSTリクエストがサーバーに発行されると、リクエストを実行したユーザーに対してトークンの検証が行われます。POSTリクエストにトークンが存在しないか、トークンが無効である場合、リクエストは根底となるデータを一切変更せずに中止されます。
既知の脆弱性を持つコンポーネントの使用（A9）
OutSystemsでは、サポートされるスタックのバージョンを定期的に更新しています。
未検証のリダイレクトと転送（A10）
インジェクション攻撃やXSSの場合と同様に、OutSystemsのビジュアルエディタは、未検証のリダイレクト攻撃につながりうるアプリケーションのパターンを設計時に警告します。またOutSystemsは、フローのリダイレクト先となるURLが、アプリケーションを実行中のドメインと同じドメインに属していることを確認する機能を備えているため、未検証のリダイレクト問題が発生するおそれがありません。