　「NEC社内で利用しているVDI環境の場合、これまでは仮想マシン1台当たり4GBのメモリ割り当てで十分でした。ところがビジネスチャットやWeb 会議ツールを頻繁に利用するようになると、4GBではアプリケーションの起動が遅くなったり、Windows全体のパフォーマンスが落ちたりするようになったのです。メモリが足りなくなるとメモリスワップが発生し、SSDを利用していてもパフォーマンスが落ちてしまいます。ユーザーからも『メモリを増やしてほしい』との要望が増え、メモリ割当量を標準で4GBから8GBに拡張しました」

Permalink | 記事への反応(0) | 01:56

2022-02-16

■このアプリを使ってない奴は馬ッ鹿ー

Tor Browser
ダークウェブにアクセスするために使用されるブラウザ。
VirtualBox
仮想マシンは、コンピュータに通常存在しないKali LinuxのようなOSを隠すことができる。
Kali Linux
ハッキングにしばしば用いられるOS。
WiFi Pineapple
コンピュータの機密データをインターネット経由で収集できるツール群。
Discord
ハッキングの心得を共有するためよく使われるポピュラーなコミュニケーションプラットフォーム。
Metasploit
ハッキングを容易にするための侵入ツール。

source: 政府当局が配布した「子どものPCに入っていたら注意すべきソフトウェアリスト」がハイレベル過ぎると話題に

Permalink | 記事への反応(0) | 04:08

2022-01-25

■本のまとめ

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

1章

【コンテナとは】

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

【コンテナ利用のメリット】

・環境依存からの解放

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

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

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

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

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

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

・リソース効率のアップ

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

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

【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 shift やOpenSearch Serviceにログを転送できる

Fluentdやfluent bitを選択できる

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

【セキュリティ設計】

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

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

　- 方法

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

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

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までであること。

・VPCのIPアドレスの割当量に気をつける

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上にソフトウェアを実行する技術

【コンテナ利用のメリット】

・環境依存からの解放

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

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

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

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

・リソース効率のアップ

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

【Dockerとは】

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

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

アプリのソースコード + Dockerfile

↓ buildでイメージの作成

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

↓ ship でイメージの保存

レジストリに保存

↓ run　コンテナの実行

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

【Dockerfileとは】

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

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

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

App Runner

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

【コスト】

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

【拡張性】

デプロイの速度　遅め

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

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

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

【信頼性】

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

【エンジニアリング観点】

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

システム要件の確認

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

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

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

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

2章まとめ、感想

3章

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

【運用設計】

モニタリングとは

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

オブザーバビリティとは

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

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

【ロギング設計】

・cloud watch logs

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

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

・Firelens

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

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

Fluentdやfluent bitを選択できる

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

【セキュリティ設計】

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

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

　- 方法

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

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

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

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

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

【信頼性設計】

・マルチ AZ 構成

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

・障害時切り離しと復旧

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

・リタイアという状態

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

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

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

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

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

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

【パフォーマンス設計】

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

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

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

・スケールアウト

スケールアウト時の注意

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

・VPCのIPアドレスの割当量に気をつける

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

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

Application Autoscaling

Fargateで使用可能

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

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

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

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

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

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

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

2022-01-09

■anond:20220109191529

まずはDockerのコンテナに侵入して、

そこから Dockerのホストに侵入することもできなくはないので、

Docker＝セキュアではないと思うけど…

まあ、なんでもそうだけど初期にあった穴はだいぶ塞がれてるはずだけど、

よく不特定多数にDocker コンテナを仮想マシンみたいに使わせるサービスあるけど、

どこまで使わせていいかは個人的にはずっと考えてしまうんだよね…

気軽にコードが実行できるサンドボックスみたいに使われてたりするけど…

Permalink | 記事への反応(1) | 19:20

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 分離の第一の候補になってくると考えます。

Permalink | 記事への反応(0) | 11:10

2021-12-30

■ 仮想化 時代の NAS 選び - やっぱり iSCSI は早い。

仮想システムを構築するにあたり、CIFS しか使えない NAS をバックアップ用に選定してきた SI 屋さんが居たので、CIFS と iSCSI のどちらが早いのか、試してみました。

テストに使う NAS は QNAP の Turbo NAS TS 110

http://www.tekwind.co.jp/products/entry_6719.php

です。もう６年以上愛用して、カビが生えてもおかしく無い程に古いし, Marvell 800Mhz という低スペックな Qnap NASです。 100Mbps 時代のモノです。

昨年、HDDがお亡くなりになったので、3Tb の HDD に交換しました。ファームウェアはこんなに古い機械でも、QNAP シリーズの最新バージョンが利用できます。

iSCSI とは

iSCSI は、今あまり見なくなりましたが SCSI ケーブル規格や、SAS ケーブル接続のハードディスクを、一般的なIP ネットワークで規格で仮想化したものです。

マウントするホストシステム側は iSCSI initiator, ディスクストレージの機能を提供する側を iSCSI Target と呼びます。

ホストから「マウントするしない」はイニシエータ側のソフトウェア的な操作で行います。これは便利な機能で、ディスクの故障などで、一時的に物理的に取り外さなければいけない場合でも、ホストからの操作だけで実際のケーブル結線の脱着を行う必要がないので、今時での SAS の外付けディスクドライブの様に、ホストもシャットダウンして電源を切り、結線を外して修理、交換する、という必要がないので、ディスクデバイスの修理をホストの電源を止めないで実施できると言う、実に便利な事ができます。

という事で、仮想環境では実に使いやすいストレージデバイスなのです。

マウントするホスト側から見ると単純に SCSI/SAS のハードディスクに過ぎません。iSCSI のストレージをマウントしてからは、通常の増設ディスクの様にフォーマットして、ホスト側で使う一般的な XFS, ext4, NTFS などのフォーマットでフォーマットする必要があります。

Linux の iSCSI ターゲット側からは、内部にターゲットとして使う「巨大なファイル」が、どん！　とあるだけです。この巨大ファイルを、イニシエータ側に仮想ディスクイメージとして提供しています。当然シンプルな仮想イメージなので、ファイルそのものをバックアップコピーすれば、ストレージのイメージそのもののバックアップができます。

※ qnap NAS の場合、iSCSI イメージは、 /share/HDx_DATA/.@iscsi.img の下にドンと作られるようです。

[Solved]How to mount iSCSI file?

https://forum.qnap.com/viewtopic.php?f=180&t=25322

[/share/HDA_DATA/.@iscsi.img] # pwd

/share/HDA_DATA/.@iscsi.img

[/share/HDA_DATA/.@iscsi.img] #

[/share/HDA_DATA/.@iscsi.img] # ls -l

-rw------- 1 admin administ 6442450944 Nov 12 20 17 iSCSI-2015ace1-5a078d66.000

-rw------- 1 admin administ 1073741824 Jun 24 09:52 iSCSI-lun4-5d0de534.000

-rw------- 1 admin administ 107374182400 Nov 4 2015 iSCSI-nss01-56399e1a.000

-rw------- 1 admin administ 5368709120 Nov 11 20 17 iSCSI-nss2015-5a06cf6d.000

-rw------- 1 admin administ 21474836480 Jun 22 17:11 iSCSI-test-56b3ce90.000

-rw------- 1 admin administ 5368709120 Jun 22 17:11 iSCSI-test-56b3ce90.001

[/share/HDA_DATA/.@iscsi.img] #

※　とても重要

CIFS/NFS のファイル共有NAS と違い、iSCSI でマウントして一つのターゲットを制御できるのは、一つのホスト、一つのイニシエータだけです。複数のホストからイニシエータでマウントする（できちゃいます）と、ファイルの排他制御は行われないので、ファイルシステム自体の不整合が起こります。

つまりファイル共有という目的には向いていない、という事です。あくまでも iSCSI ターゲットはネットワーク上の仮想ディスクです。

もっとも、一つのホストからマウントしてファイルを保存して、いったんオフラインにして、ターゲットを別なホストからマウントする、という事はできます。また、ターゲットは一つの iSCSI デバイスで複数作れるので、１台の iSCSI 装置に複数のターゲットを実装して、複数のホストから別々のターゲットイメージをマウントする事は問題ありません。

極端な話、ホストのハイパーバイザーは USB メモリやSAN ブートさせて、後はマウントした iSCSI の仮想イメージ上で、仮想マシンを動かす、HDD レスなハイパーバイザー運用もできます。

物理的な転送速度は、ネットワークの速度とディスクデバイスの性能に依存します。当然 10Gb base のネットワークカード、HUB、高規格なケーブルを使えば、論理的な性能は 10Gbps です。大抵は NAS の性能がそこまで出ないのですけどね。ヨドバシカメラあたりで売っている 4,000 円程度の 1G HUB でも、そこそこの性能が出てしまいます。

距離は、IPがつながればどこでもなので、ホストコンピュータとメインのストレージを自社のサーバールームに置き、イニシエータを動かし、バックアップ用の iSCSI ターゲットをデータセンターに置く、なんてこともできます。

【送料無料】QNAP TS－431P2（ホワイト） NAS 4ベイモデルクアッドコア CPU ／ LAN 2ポート搭載（TS431P2）

価格:56,145円

(2019/7/27 12:05時点)

感想(0件)

LUN -

iSCSI の耳慣れない言葉に LUN （論理ユニット番号 : Logical Unit Number）というのがあります。

昔の SCSI は、 SCSI バスアダプタに７番のIDを振り、残りの 0 ~ 6 のディスクや CD, Tape などに ID を振り分ける物理的な３ビットのディップスイッチやジャンパ端子が付いていました。これが SCSI アドレスです。

つまり初期のSCSI 規格では８つ分。

これが実に難物でした。特に、複数の SCSI バスアダプタカードをデュプレクス設定する場合、割り込み番号も別々にするので、手が滑ってジャンパピンを飛ばして床を這いまわって探したり、難解なディップスイッチを前に数日悩んだものです。

つまり一つの SCSI バスには 0~７の合計８台（うち大抵７番はSCSI バスカード）の物理ユニットデバイスがつながって別々に見えたという仕組みだったわけです。

ところが　SCSI バスを使った Raid コントローラが出てくると、ディスクの鈴なりが、一つの物理デバイスに見えてしまうわけです。これを「論理的な仮想番号」に分割して、システムからは、単一の鈴なり Raid ディスクを複数の論理番号に分割したわけですね。

これが LUN というヤツです。

iSCSI 機器のターゲットも、内部のソフトウェア的に複数の論理デバイスに分割して、複数のホストコンピュータから複数の物理デバイスのように見せかけるわけです。

別々な LUN は一つ、あるいは複数の iSCSI 機器によって、複数のホストに別々のディスクデバイスとして見せかけるンです。

まぁ、いい加減な説明なので、他所で調べてください。

https://en.wikipedia.org/wiki/Logical_unit_number

iSCSI ターゲットの設定 -

Qnap NAS の場合、iSCSI ターゲットはウィザード形式で簡単に作成できます。EXT4 ファイルシステム上で、オンラインでも簡単にサイズの拡大ができるので、 Windows の Storage Server のように NTFS の VHD 形式ではないので、そこそこ性能が出ますが、いかんせん古さと遅さは否めません。

Qnap NAS の iSCSI ターゲットの設定は、偉そうな Linux 系サイトに書いてある程、面倒なことはありません。ストレージマネージャから iSCSI タブにあるウィザードに従って iSCSI ターゲット名に任意の名前を付けると IQN にその文字列が追加されるだけです。わざわざ vi エディタに「正確に」綴りを間違えずに設定する必要もありません。ここでは Chap 認証は付けませんでした。

仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16405779.jpg

機械は古いのですが、逆に言うと、「古くて遅い」ため、サーバーとNASとの接続プロトコルの性能差が、如実に現れる事になります。

QNAP TVS-951X 10GBASE-T/NBASE-Tポート内蔵

10GbE 接続対応 NAS

Windows10 の Microsoft 製 iSCSI イニシエータは「コントロールパネル」＞「システムとセキュリティ」＞「管理ツール」の中にあるので、ここで、設定済の iSCSI 「ターゲットを」「検索」して選んで「接続」します。Chap 認証を付けておいた場合はターゲットで設定したパスワードが必要でしょう。

仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16412132.jpg

新規に作成して、接続した後は、フォーマットされていないため、ディスクマネージャからフォーマットして使います。ちなみに、フォーマットして利用した iSCSI ターゲットの仮想ディスクは、他のマシンでマウントすることもできます。つまり HDDを取り外して、他のPCに繋げる事と同じことですね。

ＰＲ

ちなみに opeSUSE で使うにはこんな感じになりました。

open SUSE Leap 15.1 で iSCSI NASを使ってハマった

https://islandcnt.exblog.jp/239328437/

CIFS の性能を見てみる -

一番イラつくのは、巨大なファイルの転送でしょう。という事で 3G 程ある SUSE Linux のインストール用DVDの ISO ファイルを　CIFS でコピーしてみます。

仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16414334.jpg

３分１１秒かかりました。１Gビットネットワークで 12～3% 程度の帯域を使って通信しています。明らかに古いNAS の性能が足を引っ張っているようです。

スループットは 150Mbps 程度で全体の最大１５％程度でしょうか。

仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16415832.jpg

次に iSCSI マウントしたディスクにコピーしてみます。

仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16422170.jpg

初速は出るのですが、その後は、ボロイ TS-110 の性能がモロに出ます。それでも 20 MB/s から 25 MB/s 程度は出ています。

仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16423835.jpg

２分２５秒でした。　大体２０％程度のスループットです。

数字に弱い私の脳みそですが、 iSCSI は CIFS より　1.5倍くらい早い、という事が言えます。

Zabbix で QNAP TS-110 の I/O を見てみると、前半の CIFS アクセスより後半の iSCSI アクセスの山が高い事がよくわかります。

仮想化時代の NAS 選び - やっぱり iSCSI は早い。_a0056607_16425860.jpg

CIFS を使ったリモートディスクのマウントは、他のPC からもアクセスができる、というメリットがありますが、iSCSI は単一のホストからのアクセスしかできません。<--- これ重要.... -- もっとも、ターゲットストレージを複数作って複数のサーバーから異なるデータ領域にアクセスはできますが -- バックアップ用途や、サーバーの増設ストレージとして考えれば、良い選択であると言えます。

もっとも、iSCSI デバイスそのものは、ターゲット単位で別々なホストから接続できます。しかし同じターゲットで別々のホストからイニシエータから繋ぐと、とても笑いごとにならない事態になるので、普通やりません。

ハイパーバイザー同士で一つのターゲットを共有してライブマイグレーションはしたことはあります。

こうした性能のわずかな違いが、仮想化システムのハイエンドな領域で違いとなって出てきます。なお Qnap でも open iSCSI でも Windows Storage Server でも取った領域そのままのサイズのでかいファイルが作成されるようです。

国産 NAS の「ハイエンド」と称する「LANxxxx」などのモデルでは Windows Storage Server を使って NTFS フォーマットしています。Windows Storage Server は見た目 Windows サーバーそのものなのですが、ところどころちゃんとデチューンされているようで、SOHO向けが限度です。

こういった国産 NAS メーカーの製品カタログでは、「ハイエンド」は Windows Storage Server を搭載して、低価格のNASは Unix 系のシステムで「低価格」を謳っていますが、そもそも、上位モデルは、CPUやメモリの性能が高いものが使われています。性能が違うのは当たり前なのですが、あまり性能が出ないだろうと思います。

Windows Storage Server じゃなくて、ちゃんとした Windows Server と CAL 買えよな、という事なのですね。

このあたりは独自 OSを NAS としてチューニングした Qnap や Synology, asuster などの iSCSI 機能付きの NAS を中規模ネットワークのミドルレンジの NAS として利用したほうが良いと思います。

仮想環境でのネットワークアタッチストレージ(NAS)は、本回線（構内LAN）とは切り離し、ストレージ専用のネットワークとして独立して運用させるのが基本です。サーバーとNAS間で凄まじい通信が発生します。サーバー NICが２ポート以上のものが推奨されます。

　誤解していけないのは --

iSCSI はあくまでもネットワーク上のストレージのみの機能を提供するものであり、ファイル共有の手段ではない、という事です。

NAS をCIFSで使うと NAS が持つ独自のアクセス権限を設定しなければなりません。セキュリティも当然 NAS 独自の機能で設定します。

iSCSI はあくまでも「外付け SCSI デバイス」のネットワーク版なので、マウントする側のOSそのもののファイルシステム、セキュリティ機能、アクセス制限がホスト側の機能をそのまま利用できます。セキュリティ的には、マウントする際のパスワード制限しかないので、独自のストレージネットワーク内に配置すべきで、ユーザが使う構内ネットワークに配置すべきではありません。

Permalink | 記事への反応(0) | 12:57

2021-11-04

■anond:20211104112312

Ubuntu 上の仮想マシンにWindows入れればいい。

Permalink | 記事への反応(0) | 11:24

2021-09-19

■去年DNSの設定かなんかではてなブックマークだけページ表示に3秒待たされた

あの挙動はなんだったのだろうか

仮想マシンということもからんでいそうだが結局原因はわからんかった

Permalink | 記事への反応(1) | 17:27

2021-09-17

■転職するときに重視するもの

・PCのスペック
・社内システムの新しさ

である。

これを無視している人が意外と多い。

6年前に正社員で支給されたPCが当時としてはめずらしいSSDで、速さに感動した。

そのあと派遣に戻ったらクソスペPCが支給されて、全てに1テンポ待たされる動作だった。

その後また転職したところでは仮想マシンだったのでサクサクだった。

経営者はPCのスペックで従業員のスペックも変わるのだということを知ったほうがいい。

次の職場ではゴミ PC与えられたら拒否しようと思う。

Permalink | 記事への反応(0) | 13:29

2021-07-12

■

EMPRESSによると、「バイオハザードヴィレッジ」にはDenuvoに加え、開発・販売元であるカプコンの独自 DRM 技術「Capcom Anti-Tamper」が搭載されており、これこそがカクツキの原因であったそうです。EMPRESSは「ゾンビを倒す際に発生するようなカクツキは全て修正された」と述べています。また、EMPRESSは「カプコンのDRM 技術がDenuvoの仮想マシンを難読化し、動作をさらに遅くさせていた」と述べ、怒りをあらわにしています。