「不正アクセス」を含む日記 RSS

はてなキーワード: 不正アクセスとは

2022-05-15

anond:20220515143033

回数がわかった経緯を具体的に答えて下さい

場合によっては不正アクセス被害に遭ってると相応の対応を取らなければなりません

またあなたがそこまでして黙らせたい理由を教えてください

2022-05-12

認知している最新の盗難被害から半年も経ってないだろ

不正アクセスに関しては10日も経ってないし

2022-05-05

anond:20220505161409

不正アクセスでもない限り削除したのは本人なので本人がそう判断しただけ、我々は関係ない(フェミさん理論

anond:20220505135148

設定がお粗末でパスワード漏れてそれでログインしたら、ログインした側が不正アクセスで捕まる時代から

馬鹿やった側が守られて笑った方が捕まる時代

2022-03-18

東映への不正アクセスプリキュアが一ヶ月延期

製作のためのシステム破壊されたとかなのかね。

よく聞く不正アクセスニュースだと「個人情報が○件流出しました」みたいな感じだから、それに比べたらすごいよね。

2022-03-16

東映への不正アクセスアニメ放送延期

データを見られたってレベルじゃないのかな。

運営に支障が出るくらいシステム破壊されたとか。

2022-03-13

東映不正アクセスされたってニュースがあるけど、4作品放送できないって、データとかまっさらに消されたようなレベルなんだろうな。

2022-02-20

anond:20220220162051

PR TIMES不正アクセスとおなじか。

まらないとおもうけど、実際のところはわからない。

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2022-01-22

anond:20220122092325

不正被害者」でもあり「運営上の責任果たしていない加害者」でもあるんだよ。

不正アクセスを受けて機微情報流出させた企業と同様。迅速に署名者や誤った情報を見せたオープンレターの読者に謝罪し、全可能性の確認を明言すれば加害者性は弱まるし、遅れるにつれ加害者性は高まるリスクコミュニケーションとかろくに理解してない人ばかりなんだろうな。

2021-12-31

貴社のテレワークに最適なVDI 代替の選定ガイド

VDI(仮想デスクトップ代替ソリューションの分類や、それぞれの仕組み、検討ポイントなどを解説する本連

載「テレワーク時代Web 分離入門」。 第1 回、第2 回でテレワークWeb 分離の方式の特徴を解説しました。

最終回となる今回は、方式レベルでの選定方法を紹介します。

今回のゴール

用途観点で各方式を分類すると下図のようになりますが、どんな組織にも共通する「おススメの方式」はあ

りません。

(出典:ネットワンシステムズ

今回は、読者の皆さんが自組織マッチする方式を選定できる状態をゴールとして、「結局、 どれを選べばいい

のか」という疑問に回答します。

フローチャートで分かる、

貴社のテレワークに最適なVDI 代替の選定ガイド

VDI 代替ソリューションの分類や、それぞれの仕組み、検討ポイントなどを解説する連載。最

終回は、VDI 代替ソリューション方式選定における 4 つのポイント解説して、各方式を比

します。

(2021 年03 月04 日)

26 →目次に戻る

4 つのポイント

これまで多くのユーザーと会話してきた経験から、おおよそのケースで次の4 つのポイント論点が集約されます

1. ブラウザだけで業務が完結するかどうか

2. データを処理するマシンローカルマシン大丈夫かどうか

3. データを処理するマシン物理PC大丈夫かどうか

4. 実行環境が分離されている必要があるかどうか

これらを基に、方式選定に使えるフローチャートを作ってみました。

(出典:ネットワンシステムズ

ポイント 1】ブラウザだけで業務が完結するかどうか

ブラウジングだけを安全に実行できればよいのか、それともブラウザ以外のアプリ安全に利用させたいのか」

という業務特性に関わる要件です。

テレワーク用途では、前者でよければセキュアブラウザ方式に、後者でよければそれ以外の方式にふるい分け

できますWeb 分離用途では、前者が仮想ブラウザ方式後者がそれ以外の方式となります

27 →目次に戻る

ポイント 2】データを処理するマシンローカルマシン大丈夫かどうか

次に、「 情報漏えい対策をどこまで強固なものにしたいか」という観点での要件です。

プログラムの実行環境が手元のPC となる場合データも手元のPC に保存されます。つまり、手元のPC

まれ場合、保存されているデータも盗まれしまます

ディスク暗号化している、生体認証有効にしている、だから大丈夫」と言い切れるならいいかもしれません

が、「技術進歩によって将来的に突破されるかもしれない」といった懸念払拭(ふっしょく)できない場合、仮

デスクトップ方式リモートデスクトップ方式のように、遠隔にあるマシン上で作業できる仕組みを導入する必

要があります

その一方、将来の懸念よりも、例えばコストなど別の部分を重視したい場合は、会社PC 持ち帰り方式VPN

方式)やアプリラッピング方式マッチするでしょう。

なお一般的に、リモートデスクトップ方式VPN 方式テレワーク用途のみで導入されますが、仮想 デスクトッ

方式アプリラッピング方式は、テレワークWeb 分離、どちらの用途にも利用できます

ポイント 3】データを処理するマシン物理PC大丈夫かどうか

ポイント 2】で「遠隔にあるマシン上で作業させたい」となった場合は、3 番目の検討事項として、業務継続

性を考えるとよいでしょう。

リモートデスクトップ方式場合、社内の自席にPC物理的に存在することが前提です。そのため、自席 PC

故障したときに「何もできない」状況になります

一方、仮想デスクトップ方式場合マシン仮想化されており、多くの環境において仮想マシン動作してい

サーバ群はn +1 などの方式冗長化されています。そのため、非常に強い障害耐性があります

障害耐性を高めたい場合は、仮想デスクトップ方式ベストです。業務が停止するなどのリスク運用でカバー

できる場合は、リモートデスクトップ方式を選ぶことになるでしょう。

28 →目次に戻る

ポイント 4】実行環境が分離されている必要があるかどうか

ポイント 2】で「手元のマシン上で作業させてもOK」となった場合、3 番目の検討事項として、再度情報

えい対策について考えます。【 ポイント 2】では、PC ごとデータが盗まれしまった場合を想定しましたが、ここ

ではプログラムの実行そのものに対するリスク検討します。

手元のPCプログラムを実行するということは、つまり「端末の脆弱(ぜいじゃく)性を突いたゼロデイ攻撃

を受けるリスク存在する」ことです。脆弱性を突いた攻撃を受けると、多くの場合情報を抜き取られてしま

ます

従って、例えば VPN 方式を導入する場合、「EDR(Endpoint Detection and Response)で脆弱攻撃

策を実装する」「端末のロックダウン化によってデータを保存させない」「実行できるプログラム制限する」「屋

外の公衆Wi-Fi を利用できないように制限する」「多要素認証を導入する」などの対策を併せて導入する必要

あります

このような徹底した対策継続して運用できる組織に限っては VPN 方式有効選択肢ですが、筆者としては

安易VPN 方式の導入を推奨することはできません。

VPN 方式安価かつ容易に導入できるので、昨今のテレワーク需要高まる状況では、多くの組織上記のよ

うな徹底した対策を取らずに導入してしまったと思います。取 り急ぎの暫定処置としてVPN 方式を導入してしま

場合は、これを機に腰を据えて見直してみてはいかがでしょうか。

• 参考リンク日本経済新聞「在宅時代落とし穴 国内38 社がVPN不正接続被害

また、国内に限った話ではありませんが、Verizon Communications のレポートによると、やはりVPN トラ

フィックが増加傾向にあるようです。VPN 方式の普及に伴って、悪意ある攻撃者による被害数も増加すると思い

ます

• 参考リンク:Verizon Communications「Verizon Network Report」

29 →目次に戻る

それぞれの方式比較

ここまで、要件ベースとした考え方を記載しました。選定すべき方式が大まかに見えてきたところで、ここか

らはそれぞれの方式を横に並べて、共通の項目に沿って比較します。

この比較によって、方式選定の次のステップとなる製品選定において「見落としがちな落とし穴を見つけて対策

を考える」といった検討を具体的に進めることができると思います

以降の表の見方説明しておきます。緑塗りのセルポジティブな内容、赤塗りのセルネガティブな内容、黄

塗りのセルはどちらともいえない内容です。また、それぞれの表の下部には、主に赤塗りのセルに関する特記事項

記載しています

なお単純に、緑塗りセルの多い方式が優れているわけではありません。対象業務の内容やコスト運用体制、セ

キュリティ業務継続性など、いろいろな観点からトレードオフ方式を選定することになります

できる作業

(出典:ネットワンシステムズ

仮想ブラウザ方式とセキュアブラウザ方式では、例えばファイルサーバ操作といった、ブラウザ以外のアプリ

は使えません。多くの場合Windows統合認証など Windows依存する機能も利用でません。

また、印刷に関しても確認必要です。製品ごとにサポート内容に差が出るポイントなので、方式選定の次の

ステップとなる製品選定の段階で確認した方がよいでしょう。

30 →目次に戻る

コスト

(出典:ネットワンシステムズ

会社PC 持ち帰り方式VPN 方式)とリモートデスクトップ方式は、端末のアップデート故障時の交換など、

端末台数が増えるに従って、それに対応できる人員数を確保する必要があるので、運用コストが増大する傾向に

あります

その半面、仮想デスクトップ方式は初期コストが高額ですが、メンテナンス対象マスター OS のみであり、仮

マシンを一気に展開できるので、運用員の集約化が可能です。

VDI の運用ナレッジ豊富SIer に依頼することで、作業内容の質を落とさずにコスト圧縮できる効果が期

待されます

運用

(出典:ネットワンシステムズ

仮想ブラウザ方式アプリラッピング方式、セキュアブラウザ方式は、「 Web ページが正常に表示されるかどう

か」などの動作確認を、あらかじめ実環境実施しておく必要があります。この動作確認は、運用フェーズにおい

ても継続する必要があります

また、特に仮想ブラウザ方式は、「 ブラウザタブを開き過ぎるとサーバ基盤の負荷が高騰して Web ページの閲

覧速度が急激に低下する」といったサイジング関連のトラブルが発生しやすくなります

31 →目次に戻る

セキュリティ

(出典:ネットワンシステムズ

マルウェア対策については、会社 PC 持ち帰り方式VPN 方式)やリモートデスクトップ方式仮想デスクトッ

方式は、EDRアンチウイルスソフトの導入などが別途必要です。一方、仮想ブラウザ方式アプリラッピン

方式、セキュアブラウザ方式は、「 利用終了後に環境ごとデータを削除する」「 exe 形式ファイルの実行を禁

止する」などの機能を標準で実装しています

重要情報の盗聴については、リモートデスクトップ方式仮想デスクトップ方式仮想ブラウザ方式(画面転送

型)は、画面転送型なので、暗号化通信が仮に復号されたとしても、実データが盗聴されることはないという強

みがあります

最後に、不正アクセスについては、多要素認証システムと組み合わせるなどの対策がどの方式でも必要です。

ログインに関わる操作が増えることで利便性は低下しますが、昨今の状況を鑑みると、多要素認証の導入は必須

といえます

おわりに

これで 3 回にわたる連載は終了です。いかがだったでしょうか。

セキュリティ利便性トレードオフ関係にありますが、筆者は「仮想デスクトップ方式」と「仮想ブラウザ

方式」がバランスの良い方式だと思います

仮想デスクトップ方式仮想ブラウザ方式は、「 導入によってセキュリティレベルを大きく低下させることはな

い」という点が最大のポイントです。その上で、仮想デスクトップ方式には「従来のクライアント OS と同じよう

に利用できる」という汎用(はんよう)性の高さがあり、これが他の方式より優位な点となっています。一方、仮

ブラウザ方式は、用途限定されるものの、ユーザーにとっては利便性が高く、初期コスト観点では仮想デス

トップよりも導入しやすいので、Web 分離の第一候補になってくると考えます

ログイン ユーザー登録
ようこそ ゲスト さん