クラウドの医師：ルクセンブルクでコロナウイルスと戦うための遠隔医療サービスをどのように作成したか

プラットフォームの開発を始めました...偶然です。それはすべてパンデミックから始まりました。そのため、ルクセンブルク政府は医師とのオンライン相談サービスの作成を命じました。プラットフォームから最大の利益を引き出すために、彼らは患者と一緒に医師の本格的な仕事に必要なすべてを追加することにしました。あらゆる種類の医療文書の交換、さらには医薬品の処方箋の発行も例外ではありませんでした。古いベンダーはすぐにすべてをサービスに投入しました。そして、すべての良さを安全にするために、彼らは既製の製品を私たちに求めました-私たちに必要なのは、クラウドの安全な場所にプラットフォームを展開することだけでした。



1か月半後、このサービスはルクセンブルクEDH Tier IVデータセンターで正常に機能しましたが、最初の会議でも、プロジェクト全体の弱いリンクであると認識しました。プレゼンスのポイントとは異なり、プラットフォームは自慢できませんでした。セキュリティの問題と他の12の欠点がありました。決定は明白でした-サービスは最初から行われなければなりませんでした。ルクセンブルク政府を説得するために残った。

この医者は壊れています、新しい医者を持ってきてください：なぜ私たちは新しいプラットフォームを作ることに決めました

古いプラットフォームに弾丸を置くことを提案するために、私たちはそれを一瞥する必要がありました。考えられるすべてのセキュリティ問題を修正して設計を更新する代わりに、サービスを最初から構築する方が簡単でした。その理由は3つあります。

1.システムはフレームワークなしで開発されました

このため、プラットフォームには考えられないほどの数の問題がありました。 Symfony、Laravel、Yiiなどの一般的なフレームワークを使用してサービスを作成した場合、ORMはデータベースへのクエリを準備でき、テンプレートエンジンは受信したコンテンツをエンドコードできるため、平凡な開発者でもほとんどのセキュリティ問題を回避できます。ユーザーとフォームはデフォルトでCSRFトークンで保護されており、承認と認証は通常、ほとんど箱から出して利用できます。同じケースで、プラットフォームは私たちの開発者を学生時代に懐かしくさせました-コードは大学での彼の最初の研究室での仕事とほとんど同じに見えました。



たとえば、データベース接続がどのように実装されたかを次に示します。接続資格情報は、上記の同じファイルにハードコードされています。

if (!isset($db)) {
	$db = new mysqli($db_info['host'], $db_info['user'], $db_info['pass'], $db_info['db']);
	if ($db->connect_errno) {
		die("Failed to connect to MySQL: " . $db->connect_errno);
	}
	if (!$db->set_charset("utf8")) {
		die("Error loading character set utf8 for MySQL: " . $db->connect_errno);
	}
	$db->autocommit(false);
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

2.プラットフォームには多くのセキュリティ問題がありました

監査の結果、このような欠陥があると、機密データを備えたプラットフォームはもちろん、単純なブログでも本番環境に移行できないことがわかりました。ここにそれらのいくつかがあります。

• SQLインジェクション。リクエストの90％には、事前の準備なしにユーザーが入力したデータが含まれていました。
  
  
  
  

  $sql = "
  	UPDATE user
  	SET firstname='%s', lastname='%s', born='%s', prefix='%s', phone='%s', country_res='%s', extra=%s
  	WHERE id=%d
  ;";
  $result = $db->query(sprintf($sql,
  	$_POST['firstname'],
  	$_POST['lastname'],
  	$_POST['born'],
  	$_POST['prefix'],
  	$_POST['phone'],
  	$_POST['country'],
  	isset($_POST['extra']) ? "'".$_POST['extra']."'" : "NULL",
  	$_SESSION['user']['id']
  ));
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
      

• XSSの脆弱性。カスタムコードは、出力の前にフィルタリングされませんでした。
  
  
  
  

  <button id="btn-doc-password" class="btn btn-primary btn-large pull-right" data-action="<?= $_GET['action'] ?>"><i class="fas fa-check"></i> <?= _e("Valider") ?></button>
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
      

  
  
  さらに、医師に相談する理由など、データベースに入力された情報は、データベースに書き込む前、またはページに表示する前にフィルタリングされませんでした。
• . ID , . . , ID .
• . , -. , qury-string .
  
  
  
  

  $file_dir = $settings['documents']['dir'] . $_SESSION['client']['id'] . DIRECTORY_SEPARATOR . $_GET['id_user'];
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
      

• 古いサードパーティライブラリ。古いベンダーでは、サードパーティのライブラリのバージョンをフォローしている人は誰もいませんでした。ちなみに、同じComposerを使用する代わりに、単にプロジェクトにコピーされていました。さらに、これらのサードパーティの依存関係の一部はカスタマイズされています。
• ユーザーパスワードの安全でない保管。パスワードの保存には、信頼性の低い暗号化機能が使用されていました。
  
  
  
  

  $sql = "
  	SELECT id, firstname, lastname
  	FROM user
  	WHERE id=%d AND password=PASSWORD('%s')
  ;";
  $result = $db->query(sprintf($sql, $_SESSION['user']['id'], $_POST['pass']));
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
      

• CSRFの脆弱性。CSRFトークンで保護されたフォームはありません。
• ブルートフォース攻撃に対する保護の欠如。それはただそこにありませんでした。番号。

ここで何度も続けることができますが、これらの問題は理解するのに十分です。システムに深刻な問題があったか、それ自体が深刻な問題でした。

3.コードの保守と拡張が困難でした

セキュリティの問題はすべてに限定されていませんでした。驚いたことに、プロジェクトにはバージョン管理システムがありませんでした。コードは完全に構造化されていませんでした。 Webサーバーのルートディレクトリには、ajax-new.php、ajax2.phpなどのファイルが含まれており、それらはすべてコードで使用されていました。また、レイヤー（プレゼンテーション、アプリケーション、データ）への明確な描写もありませんでした。ほとんどの場合、コードファイルはPHP、HTML、JavaScriptの混合物でした。



これらすべてが、このシステムの原始的なバックオフィスを作成するように依頼されたとき、最良の解決策は、SynataAdminと組み合わせてSymfony4を並べて展開し、既存のコードにまったく触れないことであったという事実につながりました。医師や患者さんに新たな機会を与えるように言われたら、時間と労力がかかることは明らかです。そして、自動テストの話がなかったので、何かを壊す可能性は非常に高いでしょう。



ルクセンブルク政府にとっては、上記のすべてで十分でした。新しいプラットフォームを開発するための青信号が与えられました。

Doctor Rides-Rides：新しいプラットフォームの開発方法

古いベンダーの発案を見たときでさえ、私たちは最初から新しいプラットフォームの開発の準備を始めました。そのため、新しいプラットフォームの開発が許可されたとき、すぐにMVPバージョンの作成を開始しました。 4人のPHPと3人のフロントエンド開発者のチームが約3週間半でこのタスクに対処しました。すべての作業はSymfony5で実行され、ビデオ通話とチャットのみが委任されました。これらはG-CoreMeetサービスを使用して実装されました。古いシステムのバックオフィスも役に立ちました。わずか数日でMVPに適応させることができました。その結果、システムのMVPバージョンは、古いプラットフォームの機能の80％をカバーしていました。ちなみに、これはもう1つのタスクにも使用されます。ある時点で、ルクセンブルクのe-healthエージェンシーのヘルプデスク用にMVPのクローンを作成しました。管理者がユーザーに電話をかけることができるようにします。



MVPの準備が整うと、本格的な新しいプラットフォームの開発を開始しました。APIプラットフォームとReactJSをクライアント側のNext.jsと組み合わせて、APIの基盤として使用しました。興味深いタスクがないわけではありません。

1.通知の実装

問題の1つは、通知で発生しました。APIクライアントはモバイルアプリケーションとSPAの両方である可能性があるため、組み合わせたソリューションが必要でした。

まず、顧客がSSE（Server Sent Event）を介して対話するMercureHubを選択しました。しかし、APIプラットフォームの作成者自身がこのソリューションをどのように宣伝したとしても、アプリケーションはアクティブな状態でのみ通知を受信できるため、モバイルチームはそれを拒否しました。



このようにしてFirebaseにアクセスし、モバイルデバイスでネイティブプッシュ通知のサポートを実現し、MercureHubをブラウザアプリケーションに任せました。これで、システムでイベントが発生すると、Mercure Hubで必要なプライベートチャネルを介してユーザーにイベントが通知され、さらにモバイルデバイスのプッシュがFirebaseに送信されます。



Firebaseにすべてをすぐに実装しなかったのはなぜですか？ここではすべてが単純です。Webクライアントのサポートにもかかわらず、Push APIのないブラウザー（同じSafariおよびほとんどのモバイルブラウザー）はそれで動作しません。ただし、サポートされているブラウザを使用しているユーザー向けに、Firebaseからのプッシュ通知を実装することを引き続き計画しています。

2.機能テスト

APIの機能テストを行っているときに、別の興味深い状況が発生しました。ご存知のように、それぞれがクリーンな環境で動作するはずです。しかし、毎回、ベースを上げて基本的なフィクスチャとテストに必要なフィクスチャを埋めるのは、パフォーマンスの点で高価であることが判明しました。これを回避するために、最初の段階で、エンティティマッピング（bin/console doctrine:schema:create



）に基づいてデータベースを作成し 、次に基本的なフィクスチャ（bin/console doctrine:fixtures:load



）を追加することにしました 。



次に、dama / doctrine-test-bundle拡張機能を使用して、各テストの実行がトランザクションにラップされ、テストケースの最後にコミットせずにロールバックすることを確認しました。このため、テスト中にデータベースに変更が加えられても、それらはコミットされず、実行後のデータベースはPHPUnitが起動される前と同じ状態のままになります。

エンドポイントごとに少なくとも1つのテストが作成されるように、自動レビューテストを作成しました。登録されているすべてのルートを検出し、それらのテストをチェックします。したがって、たとえば、app_appointment_createルートの場合、フォルダーにが含まれているかどうかを確認します tests/Functional/App/Appointment CreateTest.php



。



さらに、コードの品質は、phpstan-strict-rulesなどの拡張機能を備えたPHP-CS-Fixer、php-cpd、およびPHPStanによって監視されます。

3.クライアント側

医師と患者のために、同じUIと同様の機能を備えた2つの独立したクライアントアプリケーションを作成しました。それらの機能とUIの再利用を確立するために、ライブラリとアプリケーションを含むモノリポジトリを使用することにしました。同時に、アプリケーション自体は互いに独立して構築およびデプロイされますが、同じライブラリに依存している場合があります。



このアプローチにより、1つのプルリクエストで機能（ライブラリ）を作成し、それを必要なすべてのアプリケーションに統合できます。この利点により、別々のnpmライブラリと異なるリポジトリのプロジェクトに機能を実装する代わりに、モノリポジトリを使用することになりました。

モノリポジトリを構成するには、ns.jsライブラリを使用します。これにより、ボックスからReactおよびNext.jsのライブラリとアプリケーションを構築でき、プロジェクトで使用されるのはこのスタックです。ESLintとPrettierを使用してコード品質を追跡し、Jestを使用して単体テストを作成し、React TestingLibraryを使用してReactコンポーネントをテストします。

医者が到着しました：最後に何が起こったのか

わずか5か月ですべての問題が解決され、新しいプラットフォームがすべてのデバイスのユーザーに利用可能になりました。サービスのWebバージョンと、iOSおよびAndroid用のモバイルアプリケーションを準備しました。



このサービスにより、4か月以上にわたり、患者は医師や歯科医からオンラインで相談を受けることができます。それらは、オーディオ形式とビデオ形式の両方で実行できます。その結果、医師は処方箋を作成し、医療記録と検査結果を患者と安全に共有します。



このプラットフォームは、ルクセンブルクのすべての医療専門家、居住者、および労働者が利用できます。現在、彼女は国内で最大の2つの医療機関である病院で働いています。ロベールシューマン（オピトーロベールシューマン）と病院センター。エミールメリシュ（センターホスピタリエエミールメリシュ）。このサービスは、ルクセンブルクEDH TierIVデータセンターのG-CoreLabsクラウドの安全な場所に導入され、必要な仕様に従って仮想環境が構成されます。