近年、世間を騒がせているランサムウェアの被害は、VPN 装置の脆弱性を突いた所から始まりますが、その起点から、侵入したネットワークの中の、 Windows Remote Desktop (RDP) を踏み台に次々とシステムを則っていくパターンが多いようです。

そのままじゃ危険だらけ:リモートデスクトップの安全対策_a0056607_20452573.png

そこで、ここでは RDP を使ううえでの安全対策について説明してみます。


大病院で起きた大規模サイバーテロ:閉塞網が作る慢心が産んだ惨事




ポート番号の変更


Windows のリモートデスクトップを使う場合、必ずデフォルトのポートを変えておくことです。これで第一の被害は避けることができます。次のレジストリの PortNumber の値を10進数、3389 から、大胆に変更しておきます。小手先で一つ動かすのではなく、全然違う値にしておくことです。

C:¥ > regedit
 
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

そのままじゃ危険だらけ:リモートデスクトップの安全対策_a0056607_19454534.png


ポートを変更したら、リモートデスクトップで Server_IP : Port_nam で接続します。

そのままじゃ危険だらけ:リモートデスクトップの安全対策_a0056607_19464139.png



ビルトインアカウント:Administrator は使うな!無効化してリモートデスクトップ専用アカウントを作る


スタート(田)ボタン > 右クリック > コンピュータの管理、から、ローカルユーザグループで、ユーザを作成し、Administrator グループに所属させ、るとリモートデスクトップは利用できてしまいます。。

使わない Administrator ビルトインアカウントは必ず無効化してあることを確認してください。Guest アカウントも無効化しておきます。Windows サーバの場合はデフォルトで利用可能状態なので、破ってくれ、と言わんばかりの抜け穴です。

多くのランサムウェアインシデントでは、ビルトイン Administrator に対してパスワードアタック仕掛けて、この Administrator アカウントとパスワードで水平攻撃によって幾つもの Windows Server が被害を受けたようです。Administraot は共通ですから、パスワード攻撃だけであっさりと落城します。

Administrator : ******** で単純に辞書攻撃すれば破られてしまいますが、Administrator を利用禁止にしておけば、UID+++++ : ****** でかなり複雑な攻撃をしなければならないので安全です。

そのままじゃ危険だらけ:リモートデスクトップの安全対策_a0056607_19564365.png

その代わり、リモートデスクトップの専用ユーザを作成します。ここでは大人しくアルファベット英数字アカウントではなく、日本語の2バイト文字のユーザを使ってリモートデスクトップユーザとしてしまいましょう。それもアイディアです。

日本語のアカウントを作る


性善説を述べているわけではないのですが、悪意とヤル気のある連中は、まず日本国内の日本人ではなく、多くは足跡が残らない追跡が困難な海外からチャレンジして挑んできます。ここで日本語のユーザ ID を使うと、かなり彼らの「ヤル気」を削げるはず。使い勝手はいろいろ問題ありそうですが、こういう対策も効果がありそうです。

そのままじゃ危険だらけ:リモートデスクトップの安全対策_a0056607_19575372.png


Administrator の無効化



なお、Windows11 Pro 系OSでは、Administrartor グループに所属するユーザは自動的にリモートデスクトップが利用できるようになり、リモートデスクトップ機能を有効にすると管理者アカウントは自動的にセキュリティホールになってしまいます。排除することはできません。例えば、パワーユーザを作ってリモートデスクトップは使えるけれど、Administrator グループは、直接端末にログインしないとイケナイ、というルールが作れないのです。

本当に、この仕様はなんとかしてほしい。Windows がセキュリティに弱いと言われる一面です。

そのままじゃ危険だらけ:リモートデスクトップの安全対策_a0056607_19581616.png


理想を言うと、リモートデスクトップユーザは、パワーユーザー(PowerUsers)のみとして、Administrators はリモートアクセスできないようにしたいのですが、Windows では Administrator に RDP 接続を禁止する方法は無いようです。知っている方が居ればコメント下さい。

そのままじゃ危険だらけ:リモートデスクトップの安全対策_a0056607_19591338.png


サーバーへの接続キーを保存させない



万が一、悪意のある熱心な人々の侵入を受けても、被害をその PC だけに留めて置くには、端末にログインできても、その他のサーバーにはシングルサインオンできないようにするのが良いでしょう。

そのためには、PC とファイルサーバー、NAS、Web システムなどには、別々な ID/ パスワードで接続するようにして、重要なシステムやバックアップ装置などは、同じドメインで運用しないことです。

Windows には、接続した時のサービスのIDとパスワードを暗記してくれる実に脆弱な機能があるので、この「資格情報」の保存を拒否して、他のサービス、例えばファイルサーバーなどに接続する場合には、ログインダイアログを出すようにすると良いでしょう。

これにより一台の端末がハックされても、LAN 内部の共有システムの読み書き可能なデータを被害から守ることができます。最悪なのは、Administraotr でログインできてしまって、同じ Administraot で同じパスワードを使いまわしているケースです。

そのままじゃ危険だらけ:リモートデスクトップの安全対策_a0056607_20004458.png

コントロールパネル > ユーザアカウント > 資格情報マネージャー > ”Windows 資格情報の管理” から、記憶されている接続サービスを選び「削除」

そのままじゃ危険だらけ:リモートデスクトップの安全対策_a0056607_20013171.png


これで、記憶している資格情報は削除できます。



資格情報はコマンドラインでも削除できます。

C:¥ > net use ¥¥Target_name¥share /delete

でセッションを削除したら

C:¥ > cmdkey /delete:Target_name

でキーを削除します。

資格情報自体を保存させたくない。PC にログインしたら、LAN 内のサービスに接続するためには必ず ID / パスワードを求めるにはグループポリシーを修正しておきます。

C:\> gpedit

ローカルコンピュータ > コンピューター構成 > Windowsの設定 > セキュリティの設定 > ローカルセキュリティ > セキュリティオプション > 「ネットワーク アクセス: ネットワーク認証のためにパスワードおよび資格情報を保存することを許可しない」を有効にします。

そのままじゃ危険だらけ:リモートデスクトップの安全対策_a0056607_20032555.png


これで、ユーザは何かネットワークのリソースを利用するためには ID とパスワードが必要になります。

ログオフなしでファイルサーバーとのセッションを切断するには-資格情報の削除






Windows のパスワード管理は根性で(セキュリティのアリバイ程度の機能しかない)


Windows のパスワード管理は

「複雑さの要件を満たすパスワード」

で大文字小文字混じりの英数字を指定できますが、一文字だけ変えた、「ほぼ使いまわしパスワード」や、ユーザ ID と同じパスワード、同じ文字の繰り返し、qwerty パスワードなど、ほぼ「使ってはイケナイパスワード」をノーチェックで受け付けてしまいます。Linux など UNIX 系 OS ならば、使える文字種、同じアルファベットや数字の繰り返し、前回と少なくとも数文字は変えなければならない、などの厳密なパスワードポリシーで厳しくパスワードを制御できますが、Windows にはこの機能がありません。

こうなったらやっぱり、Windows のセキュリティは「セキュリティ根性論」でユーザが自ら守るしかありません。システム管理者には手が届かない機能なのです。「複雑な要件を満たすパスワード」とは、は所詮 「Windows のセキュリティ上のアリバイ機能」「一応はね、あるよ〜」程度の貧弱なもので、非常に機能が劣ります。

それでも最低限、「複雑さの要件を満たすパスワード」だけはグループポリシーでチェックしておくことです。もっとも、ドメイン上のグループポリシーの問題で、非ドメインユーザの場合は、ユーザ根性を鍛えるしかありません。実際の Administrator グループに所属するエンドユーザは無邪気にこの機能をオフにできるわけです。やっぱりパワーユーザに制限したほうがいい。


C:¥ > gpedit

そのままじゃ危険だらけ:リモートデスクトップの安全対策_a0056607_20061794.png

パスワードを間違えた場合のロックアウトポリシーを設定します。例えば「3度パスワードを間違えたら1分間ログインできない」というルールです。

辞書をつかった総当たり攻撃や、類推できるパスワード、数文字変えただけの、「準・使い回しパスワード」などの攻撃が連続するとアカウントがロックアウトされます。これはオフラインアタックには効きませんが、オンラインアタックには強力な防御手段になります。
そのままじゃ危険だらけ:リモートデスクトップの安全対策_a0056607_15480612.png


ただし、よく「あなたのパスワードの強度をチェック!」などのサイトで試そうとしないことです。悪意とその気があるサイトでは、

「へぇ〜、そういうパスワード使っているんだ」

と教えているようなもので、それを収集してアタック用の辞書に登録しているのかもしれません。信用しないことです。CrockLib-Check の Windows 版の様なスタンドアローンのものがあるといいのですが、フリーウェアでも怖いですね。


パスワードポリシー強化各種設定のいろいろ、文字数、文字種を指定



Windows Server についてはこちらをご参考ください。

今すぐできる Windows リモートデスクトップの脆弱対策




Windows11po 23H2 ローカルアカウントのパスワードを変更できない

# by islandcenter | 2023-09-25 20:35 | システム管理 | Comments(0)

大阪の医療センターで発生したランサムウェア被害は、まず、Fortigate が破られ、ここから傍系の給食システムが踏み台となって、メインの電子カルテなどの医療システムがランサムウェアの侵入を許してしまうという流れだった様です。

ここで問題となったのは、おそらく踏み台となったシステムが、脆弱なパスワード、おそらく「よくあるパスワード」で Administrator アカウントで RDP 接続できたこと。また、構内ネットワークの多くの Windows マシンが Administrator は「右にならえ」の構成だったことが推測できます。

実際には、その裏にある医療業界全体にある、「医療システムはネットワークから分離している」という業界全体に盲目的に信じられている「閉鎖網神話」が大きな原因なのですが、じゃあ、私たち IT 業界の技術者にとって、予算をかけずに今すぐできる対策って何だろう、と考えると、 今回のインシデントで被害を拡大させた Windows Server のリモートデスクトップ(RDP) の設定をどうするか、という点です。

大病院で起きた大規模サイバーテロ:閉塞網が作る慢心が産んだ惨事


調 査 報 告 書 2023 年 3 月 28 日 地方独立行政法人大阪府立病院機構
大阪急性期・総合医療センター


という事で、ここでは無料で Windows Server のリモートデスクトップ (以下RDP) をどう設定すべきかという点を、より具体的に取り上げてみます。全て費用がかからないことなので、今すぐ実践できることです



Windows11 以降のリモートデスクトップ:よくあるトラブル

Windows11po 23H2 ローカルアカウントのパスワードを変更できない


府立総合医療センターでの復旧後の運用ポリシー


府立総合医療センターでの調査報告では、復旧後、次の点を取り上げて運用ポリシーとしている層です。

管理者パスワード長:12文字
ログイン失敗でロックアウト:3回失敗で15分ロックアウト
Builtin-Administrator ; 無効
管理者用 ID / パスワード:ユニークで使いまわし厳禁
リモートデスクトップポート:デフォルト√ 以外

現在は、プライベートネットワークでも、システムの仮想化は一般化しています。多くの顧客環境ではベアメタルサーバーのコンソールを使うのではなく、RDP で操作することが一般的になっているでしょうから、 RDP 接続のセキュリティの確保は重要です。

Windows Server 2022 を対象に RDP の設定内容を検証してみます。



Windows リモートデスクトップの有効化


Windows RDP を有効化するには、スタート(田)> 歯車 > システムにある「リモートデスクトップ」を有効化することに始まります。

今すぐできる Windows リモートデスクトップの脆弱対策:医療機関でのランサムウェア被害からの反省で私達が学ぶもの_a0056607_15222701.png

次に、「サーバーマネージャー」のローカルサーバーから、「リモート管理」、「リモートデスクトップ」を有効化します。

今すぐできる Windows リモートデスクトップの脆弱対策:医療機関でのランサムウェア被害からの反省で私達が学ぶもの_a0056607_15230053.png

これで、 Administrator から MSTSC を使った RDP 接続ができるのですが、デフォルトポート3389 は使わずに、安全のため別なポートに割り当てる事になります。

以下のレジストリに、ポート番号が設定されるため、別なポート番号を割り当てます。


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

値は16進数で表示されますが、十進表示に変えてランダムな値を与えます。

ここで重要なのは、小手先の下一桁を変えるのではなく、大胆に数値を変えること。また、運用中のサーバ毎にポート番号を変えることを検討します。攻撃者にとっては少しでも近寄りがたい設定にすることです。

今すぐできる Windows リモートデスクトップの脆弱対策:医療機関でのランサムウェア被害からの反省で私達が学ぶもの_a0056607_15235380.png

接続する時は

C:\> MSTSC /V:IP-adder:Port

で接続するか、リモートデスクトップアプリケーションから接続先に「IP-Adder:Port」 を指定する形になります。

今すぐできる Windows リモートデスクトップの脆弱対策:医療機関でのランサムウェア被害からの反省で私達が学ぶもの_a0056607_15242401.png

今すぐできる Windows リモートデスクトップの脆弱対策:医療機関でのランサムウェア被害からの反省で私達が学ぶもの_a0056607_15250639.png



ビルトイン Administrator アカウントから一般ユーザへ


スタート(田)右ボタン> コンピュータの管理、から、Administrator とは異なるユーザを登録して、 Administrators と Remote Desktop グループに所属するユーザを作成します。

今すぐできる Windows リモートデスクトップの脆弱対策:医療機関でのランサムウェア被害からの反省で私達が学ぶもの_a0056607_15264262.png





ここで重要なのは、ユーザは二人以上作成し、それぞれ異なるパスワードを設定すること、つまり Administrator 権限を同じユーザとパスワードで使い回さないことです。

今すぐできる Windows リモートデスクトップの脆弱対策:医療機関でのランサムウェア被害からの反省で私達が学ぶもの_a0056607_15493921.png





Administrator ビルトインアカウントの無効化


実際に、Administrator 以外の管理者アカウントを作成したら、作成したユーザで、 RDP 接続して、ビルトイン Administrator の無効化をチェックして、無効化します。

ここで無効化できなければ、 Administrator 権限は正しく設定できていないということですね。

今すぐできる Windows リモートデスクトップの脆弱対策:医療機関でのランサムウェア被害からの反省で私達が学ぶもの_a0056607_15264262.png
今すぐできる Windows リモートデスクトップの脆弱対策:医療機関でのランサムウェア被害からの反省で私達が学ぶもの_a0056607_15272669.png


パスワードの厳格運用



グループポリシーエディタで、パスワードのポリシーを変更します。

C:¥ > gpedit

を実行して、アカウントのパスワードポリシーをより厳しいポリシーに設定します。

・パスワード長:8文字から12文字程度にするのが良いでしょう。長すぎても辛くなるばかりです。
・パスワードの有効期間:何日おきにパスワードを変更すべきか。近年、このポリシーでパスワードを強制的にへんこうさせるのはデメリットという意見も多く見られます。
・パスワードの履歴保存:3から10回程度は変更履歴を残して、パスワードを変更するたびに使い回さない様に設定します。
・複雑さの要件を満たすパスワード:有効にします。大文字、小文字、数字、記号を使ったパスワードが強制されます。

今すぐできる Windows リモートデスクトップの脆弱対策:医療機関でのランサムウェア被害からの反省で私達が学ぶもの_a0056607_15292176.png

パスワードを複雑化することで、辞書などを使ったブルートフォースアタック(力任せ総当り攻撃)に対して有効です。パスワードを間違えると1分とかの間ロックされるので、一瞬で破られるパスワード攻撃に非常に有効です。

ロックアウト期間:数回のパスワードミスで、数分間ログインできなくなります。

今すぐできる Windows リモートデスクトップの脆弱対策:医療機関でのランサムウェア被害からの反省で私達が学ぶもの_a0056607_15294993.png

この数字は微妙で、ログオン失敗回数を極端に短くすると当然ですが運用に影響しますし、ロック時間を極端に長くすれば、それはまた新しい意味で脅威となります。ロック時間を0にセットするとパスワードを間違えると悪夢です。ログインできなくなります。充分注意してセットしてください。

グループポリシーエディタを終了したら、グループポリシーをアップデートします。

C:¥ > gpupdate

このパスワードポリシーは、管理者が自らに設定するもので、当然自分で解除もできてしまうという事。つまりこの設定は自分に課すものであり、管理者は自らの根性でパスワードのセキュリティを管理しなくてはなりません。結局はセキュリティ根性論です。



Windows のパスワード管理はユーザ任せの根性論


Windows でのパスワード変更ルールは、複雑さを求めるこのルールしかなく、基本的に「セキュリティ根性論」に基きます。セキュリティ根性論は、システムの機能によってセキュリティが維持することができず、人的機能(ユーザが複雑なパスワードを覚えて自分で管理すること)に頼る事です。

Linux のパスワード管理の様に、一文字だけ変えた、ほぼ使いまわしに近いパスワードや、ユーザ ID と同じパスワード、Crack-Lib に登録されている、「よくあるイケナイパスワードのリスト」をチェックするような機能はありません。自分自身のルールに従って、複雑で覚えやすく、他人にわかりにくいパスワードを自己管理しなければなりません。セキュリティ根性論に基づく管理が必要です。

Windows はセキュリティ機能が低く、人的リソースによる力技、セキュリティ根性に依存するケースが多くあります。

パスワードポリシー強化各種設定のいろいろ、文字数、文字種を指定


他に、 RDP の接続数制限(一つか2つのセッションしか許可しない)とか、ファイアウォール設定を使って、特定のターミナルしか接続できない様に設定するなどの対策を検討しても良いでしょう。






単一のプラットフォームに依存する危険


今回のインシデントの中に、仮想環境のプラットフォーム自体が侵食されて壊滅的な損害を受けています。おそらく Windows の Hyper-V 環境ではないかな、と想像できます。

もし、仮想化基盤が Windows ではないプラットフォームを使っていれば、仮想プラットフォーム自体の侵害は受けなかったかもしれません。また、ニップンの事例ではバックアップ自体もランサムウェアに侵食されたようです。

国内の製粉大手がサイバー攻撃の被害に、ランサムウェア対策にはオフラインバックアップが有効

BCP想定を上回ったニップンへのサイバー攻撃についてまとめてみた

果たしてバックアップシステムも Windows である必要があるのかどうか。というか、システム全体を Windows だけのモノ・プラットフォームで構成するのはどんなものなのかという危機感を改めて感じてしまいます。

もちろん、人的リソースの不足もあり、モノプラットフォームで構築したほうが、導入コスト、メンテナンスコストも削減できるという意見は充分承知していますが、どこかキーとなる重要部分に別なプラットフォームを選択する、という手段も一つの防御手段としてありえるのではないかと考えていますが如何でしょうか。異なるいくつかのプラットフォームがあれば、攻撃する側も複雑なテクニックが必要となるはずです。

攻撃者が、第一のターゲットを克服して、次を狙った時に、同じプラットフォームで同じコンセプト、同じ ID とパスワードで管理されているシステムがずらりと並んでいる姿を見たときの「シメシメ、やった!」感は想像に難くない。もし違ったプラットフォームがあれば、それほど被害は拡大しなかったのではないかという事は言い得るでしょう。

攻撃する側の心理としては、第一弾が突破できればすぐに攻撃する、という事はおそらくやりません。脆弱性を見つけた後、ターゲットとなるシステムの価値を見極めるために、必ず自分の活動が見破られることなく、数日間、あるいは数週間に渡って潜伏して内部を痕跡が残らぬよう走査するでしょう。システム全体のセキュリティポリシーに共通する脆弱性を確認しつつ、最大の効果を得られる手段を最小の技術、手間で攻撃に移ることでしょう。悪意のある侵入者は痕跡をできるだけ残したくないものです。

そこにもう一つの異なるシステムがあって、そこが攻撃する本丸だった場合、そのシステムが異なるプラットフォーム、ポリシーで運用されていたら、そう簡単に手を出せるでしょうか。忍び込んだ家の中に一見強固に見えるもう一つの金庫、ファイアウォールがあれば、果たしてバールのようなもので音を立ててこじ開ける危険は侵したがらないはずです。できれば引き出しの中をチェックして終わりにしたい。できれば引き出しを開ける時に使えた鍵が使える範囲で最大限の獲物を得たい。

もっとも、 Windows を単一の AD ドメインで運用すること自体が問題なのかもしれません。ドメインに依存しない場合は、スタンドアローンで運用するような構成も工夫すべきかもしれませんね。Windows そのものは、脆弱性がなくても、Windows の管理自体を Administrator でログインして行わねければならないことです。

複雑なシステムを、単一のプラットフォームで運用することは、運用コストの削減に繋がります。しかし、単一のコンセプトで運用すると、セキュリティのリスクも均一に広がってしまい勝ちになります。単一の Windows ドメインで運用することは、管理者アカウントの漏洩に対して脆弱性を晒す場合があるのかもしれません。そこで、傍系のシステムを別アカウントや、別なプラットフォームで運用管理することは、安全性の担保にもなりますが、一方では運用コストの増大にも繋がります。システムの複雑さは、セキュリティ自体を複雑化させ、安全性を高めますが、一方では運用の複雑さによる不具合やエラーや誤処理を生み出します。

結局はセキュリティ根性論であり、セキュリティの担保は人的リソースへの投資がどれだけできるのかの問題なのですね。

対策そのものは無料です。その代わり人的資源が必要だという点です。




# by islandcenter | 2023-09-12 15:47 | システム管理 | Comments(0)

大阪急性期・総合医療センター(大阪府立総合医療センター)で昨年 2022/10 に発生したサイバー攻撃に関する調査報告書を読みました。

大病院を「修羅場」に変えたサイバー攻撃 異変はひそかに忍び寄った

システム障害じゃない!「犯行声明」で始まったランサムウェアの悪夢

asahi.com の記事を見た時、「ああそう言えばあったなぁ」程度のものでしたが、実際に中身を読むと実に多くの事が書かれているので、タメになります。


情報セキュリティインシデント調査委員会報告書について

調 査 報 告 書

大阪急性期・総合医療センター 情報セキュリティインシデント調査報告書 概要 2023.3.28 調査委員会

大病院で起きた大規模サイバーテロ:閉塞網が作る慢心が産んだ惨事_a0056607_22193011.png

医療機関は閉域網


特に

"医療機関は閉域網だからセキュリティは問題ない」といった誤った閉域網神話の中で、セキュリティに関する意識が薄れていた"

という要因の分析には心が折れます。

医療機関もそうですが、製造業などでも生産装置の制御のため、古いオペレーティングシステムを使った生産・品証システムは多くあります。何十年もの償却期間が必要なシステムですから、周辺機器も併せて、何十年も使うわけです。当たり前のように、インターネットには繋がらない事が前提で、その様な機器が使われているわけなんですが、「インターネットには繋がっていない」のではなく「インターネットに繋がる可能性がある」という前提で考えるべきなのでしょう。

この病院には、新品で2013年に購入した当時最新の医療機器の制御端末が使用されています。当初の購入時点で、その制御端末は、既に販売およびサポートが終了している、あの懐かしい香り漂うWindows 2000です。この事実は、胸を打つようなエピソードですね。なぜなら、そのように古いシステムがなぜ現代の最新医療機器と一緒に提供されているのか、疑問に思われるからです。しかしこの背後には、「医療機関はインターネットに接続されない」という暗黙の了解があります。この背景により、ベンダーも顧客の医療機関も、セーフティガードの不足した医療機器を、ローカルネットワークの一部として考え、その意識の下で販売および利用してきた経緯があります。



実際の侵入の経緯


実際には病院の中核の医療関係のシステムが狙われたのではなく、取引先の給食事業者が運営するクラウドから侵入され、これを踏み台に病院の中核が襲われた、といういきさつの様です。

いわゆる傍系。傍系から中核のシステムに入られたわけです。病院内の給食用システムは、NIC を二枚刺しして、本来セキュアであるべきデディケートした構内システムとルーティングできる設定だった。攻撃者は、この給食システムの脆弱性を見た時、心が踊ったことでしょう。稲葉山の城攻めで致命的な中入りのポイントを見つけた織田信長の気持ち、と言うのは簡単ですが、その前にズラリと重要なシステムが並んでいるのです。

実際、インターネットが使える側の配線と、医療システム側のネットワークはケーブル二本差で両方のネットワークが見える構成だったものがいくつかあった。そこを踏み台にして、共用パスワードで難なく侵入できたらしい。

IT 系メディアは、パスワードが使い回されたり、中核の電子カルテにウィルスソフトウェアが入っていなかったなどの点を「ずさん」と片付けていますが、これらは全て「医療機関は閉域網」という暗黙の了解の元での脆弱性の放置なのです。システムベンダーにとっては、インターネットにも繋がらない機器にどうやってパッチを当てるのか、ウィルスパターンの入手、配布、更新はどうするのか、運用上のセキュリティの担保はどうるるのか。これらはベンダーとしては考える必要は無いわけですし、顧客側のシステム運用担当者にとっても、休日出勤して深夜にパッチと再起動、動作確認、みたいなヘビーな業務から開放されるなら、「プロダクトネットワークは閉域網にある」という前提は極上のセキュリティ対策なのです。

病院の診察室でよく見るんですよ、レントゲンの画面を NANAO のプロモニタで見せながら、左隅のスタートボタンのデザインがやけに「酸っぱい思い出アイコン」なんですね。これ医療業界ではほとんど常識なんでしょう。これ、医療機関では当たり前なのは、病院へ言ってみれば「実感」します。

実際、医療機関のみならず、製造業や重要な公共的なインフラなどでも、古いオペレーティングシステムは閉塞網の中で使われ続けています。


医療業界に蔓延る「閉塞網安全神話」


読めてくるのは、個々の運用方法や設定の不具合、不備ではありません。パスワードの運用問題もセキュリティ対策の不備も、全てが「閉塞網安全神話」を前提としてシステムが構築されている点です。

これは決して利用者、運用者である医療機関側だけの問題であるとは言い切れないのです。医療機関を取り巻く医療機器ベンダー、医療関係のシステムインテグレータ、彼らを取り巻く「医療に関する IT ビジネス」業界全体が抱えている根深い問題じゃないでしょうか。報告書の中にも、このインシデントを天下国家ひとまとめにして議論すべき問題だとまとめていますが、私も同意します。

医療機器ベンダーにとっては機器が売れて定期的な消耗品ビジネスが成功すればいいわけで、情報システムとしての「セキュリティ」は面倒なので売りたくないのです。また、インテグレータ側としては、セキュリティ要件、情報漏洩などの要求要件の高い医療機関相手に、手間と時間がかかるソフトウェアとしてのセキュリティシステムの運用を安易に売りたくない。医療機関としても形のないシステムの高度な運用手順やセキュリティソフトウェアなんかにはお金を払いたくない。病院側としては提供したいのは医療期間としての医療技術であって、IT システムを使った医療じゃない。これは、IT を軽視して動かないシステムを続けて運用してきたどこかの金融機関と同じ IT の軽視なんですね。

そこに救世主の様に

「閉塞網だから」

という理由でコストカットされるわけだから、IT ベンダー、医療機器ベンダー、インテグレータ、医療機関にとっては、閉塞網というコトバは難題全てをチャラにする便利なキラーワードだったのでは無いでしょうか。


硬直化する運用ポリシー


システムは運用当時から、どの様に運用され、どこのどの部分を誰が、どの組織が担当するのかが決められるわけですが、当然最初に作っtルールは、硬直化したり、時代遅れになったりするものです。

運用者側もサービスを提供するベンダーも、早くその事実に気がついて、セキュリティや運用ポリシーについて見直す必要があるのです。その際、中心になるのは、運用者である、顧客側。と言ってしまうのは、サービス提供者側からの意見であり、一方的でしょう。

しかし、システムは、正常系の運用が最大限に担保されるもの、と言った法則がまかり通り、異常系のトラブルは、実地試験や BCP 対策の中に組み込まれトレーニングや検証など、中々提案しにくいものです。

ある銀行では、システム統合のため、ATM を二日間止めて、システム移行のリハーサルを行ったことがありましたが、そう言った提案は中々ベンダー側からは出ません。顧客からの提案があれば前向きになれるものです。

同時に惨事復旧やセキュリティチェック、基幹系システムのパッチ当てなどは、中々ベンダー側から顧客には提案できないものです。

顧客にとっては、金を生むネタではないのです。

セキュリティをネットワークのエッジで防御する手法は既に時代遅れなのでしょう。全ての機器がネットワークに向けて広がっているゼロ・トラストであるという前提で物事を考える時代に変化してきているのですが、思考が21世紀初頭の Windows 2000 時代のまま硬直している。当たり前ですけど、個々の単位でセキュリティを設計して運用するには、当然、お金も人材も時間もかかる作業です。

PDCA サイクルという考え方自体がそれほど新しいコンセプトでもなかったはずなのに、セキュリティの考え方はどこに行ったのか。




バックアップが救いだった


幸いな事に影響の大きな情報漏洩の形跡は見当たらなかったこと。またオフラインバックアップデータからの復旧が可能だったことは幸いです。重要なデータをランサムウェアで破壊されたわけですから、やっぱりバックアップは重要です。

ランサムウェアでバックアップも全滅したニップンの事例よりは、まだ救いがあった。

システム運用者側からすると、バックアップは取れて当たり前で、データのリストアはできればやりたくない事です。私の取引先のシステム管理者さんの中には

「バックアップからリストアする必要に迫られたら管理者失格」

と言い切るお客様がいらっしゃいました。やったことがあるのでよくわかりますが、ベンダー側の技術者もリストアなんてしたくない。特にバックアップシステムも破壊された場合は、テープメディアがワンビシアーカイブさんみたいな山奥の金庫にオフラインで安全に保管されていても、もう地獄です。何しろリストアする前に金庫の中の何十本もあるテープを全部読み込んで、テープのデータベースから作り直さなければならない。そこから、リストアできるデータをピックアップするという気持ちが折れそうな作業が必要です。それを全フロアからのいつ終わるんだというエンドユーザさんからの冷たい視線を感じながら作業するわけです。

データ損失のタイミングとバックアップのタイムラグでどの様な不整合があるかわからない。やっぱりリストアはやりたくないことの一つです。

リストアが必要なインシデントが発生したらそれはシステム管理者として負けです。リストア作業は航空機のパイロットなら滅多に経験しない「重要インシデント」の最悪の結果です。一つ余計なことを言わせてもらえれば、主業務システムとは全く異なるオペレーティングシステムでバックアップを取るべきだと考えます。


--
報告書全体は、如何にも「第三者視点」で書かれています。ここで特定のベンダーを非難するとか、顧客側組織の問題として終止していない点は救いがあるでしょう。全体として感じるのは、医療機関という特殊な事例に有りがちな「デディケートしたネットワーク」を見て見ぬふりをしてきた医療業界を取り巻くITシステムの安全神話をトコトン打ち壊す報告だったという印章です。

"国や自治体レベルでセキュリティ機能を集約したり、医療サービスにおける共通プラットフォームを確立したりするなどの検討を、厚生労働省に限らず、国全体で国民の命を守るための医療機関のセキュリティ体制の検討が必要である"

業界のみならず、国家や自治体も積極的に関与して取り組むべき課題であるとしています。

このシステムトラブルで、患者の生命に危険が及んだとかの報告は含まれていません。幸いにも、このインシデントが直接患者の生命に関わる事故に繋がったということはなかったようです。しかしコロナ禍で全国の医療機関が逼迫していた時期で、地域の緊急医療を担うべき立場の医療機関での事故ですから、決して平和に終わったとは思えません。その点を報告書にはありませんが、このインシデントに関わった担当者全員が感じているでしょう。むしろ、報告の中でメンバーのメンタル面でのサポートについても記載されている点は、救いを感じます。


全員に管理者権限、パスワードは全部共通、脆弱性は放置…… ランサム攻撃受けた大阪急性期・総合医療センターのずさんな体制

大阪急性期・総合医療センターがランサムウエア被害の報告書公開、実態を読み解く

ランサムウエア被害の大阪の病院、初動から全面復旧まで2カ月間の全貌


ITにおける標準化策定:機能のクラス分け
パスワードポリシー強化各種設定のいろいろ、文字数、文字種を指定
今すぐできる Windows リモートデスクトップの脆弱対策:医療機関でのランサムウェア被害からの反省で私達が学ぶもの

そのままじゃ危険だらけ:リモートデスクトップの安全対策








# by islandcenter | 2023-08-21 22:41 | システム管理 | Comments(0)

X (Twitter) が有料プランを発表して、何れ今は無料で使えるフリーミアムに支えられてきたネットワークサービスが有料化。フリーミアムがオワコン化し始めているようです。

サブスクリプションがフリーミアムをオワコン化、Web 2.0 ビジネスの終焉。Gooogle アカウントが有料化する日_a0056607_16004896.jpg

元々は各種音楽サービスが、サブスクリプションサービスを始めて成功を収めたサービスの有償化です。もっと遡れば、無料だった Linux のディストリビューションが有償化して、果たして Linux のサブスクリプションビジネスは成功するのだろうか、と疑念があったのは随分昔の話だと思います。しかし RedHat も SUSE もビジネスモデルが失敗しているという話は聞きません。

私達が今、無料で享受しているフリーミアムサービスであっても末端まで有償化、プレミアム化へ移行するのではないかと思われてしまいます。

私達が無料で使っている Google や Yahoo のサービスはいつか、サブスクリプション化して有償サービスのみになるのか。



かつては無料だった新聞社のオンライン版

かつては、朝日新聞も日経もオンライン版は無料だったことを覚えている人はどれくらいいるでしょうか。新聞各社が、オンラインサービスを始めた頃は、まだ有償の物理的な「新聞紙」がビジネスになっていた時代に、無料で新聞がオンラインで読めたわけです。しかし、フィジカルな「新聞」ビジネスが曲がり角を迎えた頃、新聞各社は、自社のニュースサイトを有償サービス化しました。

今、ある事件に付いて、複数の視点から眺めてみたい、と言う場合、かつては、各社の記事を見比べる事ができたものですが、今は各新聞社の購読サービスに加入しないと見出し記事を眺めて終わりの時代へと入っていきます。

従来の IT 系メディアはまだ無償で過去記事も併せて見ることができますが、日経BPの様に、無償で読めない過去記事など多くなりました。

フリーミアムの仕組み

フリーミアムモデルは、基本的な機能やコンテンツを無料で提供し、一部の高度な機能や追加コンテンツに対して課金を行うビジネスモデルです。このモデルは、ユーザーにサービスやアプリケーションを試してもらい、その価値を実感してもらった後に課金を促す方法です。

よくある無料サービスで、サービス内課金を行うものですね。



フリーミアムからサブスクリプションへの移行

フリーミアムからサブスクリプションへと移行する中で、様々な市場の問題点があります。まだまだフリーミアムモデルが踏みとどまる余地とはどんなものでしょう。

市場の飽和度: サブスクリプションモデルが増えると、市場はますます競争激化し、利用者が選択肢を持つことになります。この競争は価格と価値提供に関してますます重要になります。フリーミアムモデルは、無料で提供される基本機能が他のサービスと比べて魅力的である場合には、競争力を保つことができるかもしれません。

コンテンツの質とユーザー体験: サブスクリプションモデルは、安定的な収益源を提供する可能性がありますが、ユーザーはその対価として高品質なコンテンツやサービスを期待します。フリーミアムモデルが提供する無料コンテンツも、利用者にとって十分な価値を持っているかが重要です。

新規ユーザー獲得と定着: フリーミアムモデルは、無料で使ってもらうことでユーザーを獲得し、その後に課金を促す一方、サブスクリプションモデルは直接収益を得ることを重視します。新規ユーザーを獲得しやすいのはフリーミアムですが、その後のユーザーの定着と課金に関してはサブスクリプションモデルの方が有利かもしれません。

市場のトレンドと消費者の好み: 時代や地域によっても、人々の消費傾向や好みは変化します。一時的にはサブスクリプションモデルが主流とされても、その後のトレンドの変化によってフリーミアムモデルが再び注目を浴びることもあります。



顧客が払う費用には上限がある

サブスクリプションサービスのユーザ側の問題点としては、払える費用には上限があるということです。

例えば音楽のサブスクリプションサービスは数々あれど、一つのサービスでワンストップできない事です。こっちのサービスが良さそうで入ってみたけれど、結局は満足できずに別なサービスに入ってみたりでは、上限がありません。一方で懐の中身には上限があります。

結局、どのサービスも満足できない。

私達が支払える費用には上限がある以上、0か1かの選択肢は非常に厳しい。興味があるサブスクリプション全てを契約する訳にはいかない。そんな中で、フリーミアムなサービスは魅力的だった。フリーミアムからマネタイズする方法の一つとしてサブスクリプションモデルが使われているわけですが、お得感のあるサービスはなかなか見つからないのです。


大手 GAFAM に飲まれるフリーミアム

私は Evernote を何年も利用して満足して使っています。しかし、Evernote には、Microsoft OneNote や Apple のメモ帳、Google Keep などの後発のアプリケーションに飲み込まれてきました。オンラインミーティングと言えば、Zoom だった時代は短く、いまや Microsoft Teams に完全に市場が奪われている状態です。Slack もいずれどこか大手の類似サービスに飲み込まれる日が来るかもしれない。

Microsoft OneNote は Office356 サブスクリプションの言わば「オマケ」の様なものだし、 Apple のメモ帳は、iPhone の付属品に過ぎません。Teams は、Sylype の「残骸」といっても良さそうですが、ここに来て Office の一部として日の目を見たようです。

これらは、言わば「本家」の付属サービスに過ぎず、フリーミアムのスタートアップが成功した後のマーケティングの結果、本家のオマケとして勢いを伸ばしてきました。

所詮、フリーミアムのスタートアップビジネスが対抗できるものではなかったのです。

フリーミアムのビジネスモデルのあり方は、サブスクリプションサービスと、大手 GAFAM との隙間に押し込まれ、今や立ち位置がない。フリーミアムはオワコン化しています。


Google がサブスクリプション化する日

果たして、今や IT 業界の「巨人」となった、 Google アカウントですが、ほぼ世界人口の半分は持っているであろう、Google アカウントが、有料化、サブスクリプション化する日は来るのでしょうか。

Google の収益モデルは広告なので、そう簡単に有償化にはならないかもしれませんが、無料アカウントなら広告だらけの検索結果でも、ベーシックな有償アカウントを使った場合は、検索結果からリスティング広告を排除する。プレミアムアカウントなら、AI による検索結果や、外国語の翻訳結果をリストに出すとか、Google Suite の 1Tb 程度のフリーミアムな差別化は可能かもしれません。

すでに Google Suite には有料版があるわけだから、Google Suite の有料ユーザには検索結果や Google のサービスに簡単な色をつける、なんてことはスグにもできそうです。そもそも Google が利用者に課金して、ある程度実績のある G-Suite のサービス会員には特別なサービス、AI サービスの提供は Youtube Premiam の付与なんかが始まってもおかしくない。そもそも、価格的には Microsoft Office 356 などより有利なんですね。

Google が G-Suite にプレミアム感を帯与したら、結構なインパクトはあるのかもしれない。Google は言わずとしれた、スマートフォンOS の一大サプライヤーなのです。今やパーソナルコンピューターより人口あたりの普及率が高く、低価格PCより、高機能、高価格化したスマートフォンプラットフォームに何らかな付加価値をつけて課金化することは不可能ではない。Microsoft が Surface Duo を売り込んでも、所詮は Android でしかない。Android 端末で OneDrive を使いたがるユーザ層は特異な存在ですが、 Google Drive を使うユーザは別に特別じゃない。月々 ¥980 程度の G Swite ベーシック会員に Youtube Premium を付与するだけでも、Google はユーザを確保できるかもしれませんね。

スマートフォンという、飛び道具が Surface くらいしかない Microsoft には勝ち目がないでしょう。その代わり Microsoft は Office という武器を使い倒す戦略でしょう。

こうなると、DropBox の様な、クラウドストレージのスタートアップサービスは、付加価値がなくますます苦しむ事になりそう。

Twitter (X)有償化、イーロン・マスクは下剋上で Web 2.0 をオワコンか?



--
フリーミアムは、21世紀に入ってからのItビジネスの一つのビジネスモデルとして成功してきましたが、スタートアップ企業のその方向性は大きく揺らいでいます。サブスクリプション化する大手のビジネスモデルと、小さなアイディアを大手巨人が、主要ビジネスのオマケとして実装することで、オワコン化しているのです。

サブスクリプションモデルは今は模索状態でしょう。小さなスタートアップで成功しても、大手が参入すれば木っ端微塵になってしまう。そして乱立するサブスクリプションサービスが、顧客の選択肢を混乱させる。

果たして私達は何にお金を払えば良いのか。

答えはまだ出ていないのです。





# by islandcenter | 2023-08-11 16:01 | 雑文 | Comments(0)

SUSE Linux Enterprise 15 sp5 Install in Test Environment or Slow Internet Connection.


SUSE Linux Entreprise 15 sp5 がこの6月にリリースされました。

SLES 15 は 2018 年にリリースされ、ほぼ毎年初夏の頃に SP 版がリリースされてきました。従来はマイナーバージョンアップはほぼ一年半ごとでした。 SLE 15 以降は開発のスピードが上がっているようです。

SP4 で終わりかなと思っていたのですが、 SP5 のリリースです。openSUSE プロジェクトでは Leap 15.6 のプランもあるようなので、本家 SLE も SP6 が出てくるのでしょうか。

openSUSE Leap 15.5 リリースされました。 インストールとファーストインプレッション



SLES15sp5 のリリースノートはこちら

SUSE Linux Enterprise Server 15 SP5 Release Notes

順当にオープンソースの上がったバージョンに従って細かな点が改善されています。

例えば「仮想マシンあたりのサポート数を 288 から 768 VCPU に増やしました」など、個人的には KVM ハイパーバイザーに SLES 推している立場としては、KVM 周りの改善に興味があります。

また、手元の Apple Silicon M1 シリーズの UTM 仮想環境で aarch64 版が動作してくれています。Rasberry Pi 以外、あまり aarch64 版のハードウェア環境が手に入らないので、一般的な Apple Mac 上で仮想化して動くというのは嬉しいですね。mac でも SUSE Linux が使える。2023/6 現在よく調べたら、他のディストリビューションではGUIも含めて Apple 仮想化機能を使って ARM 版が全部動くのは非常に少ないのです。

M1 mac で Linux 仮想化 SUSE Linux Enterprise15sp5 Beta が UTM で動いた



SLE15 の評価版・テストインストール

それでは、SLES15 をインストール方法を順に追ってみてみましょう。評価版をインストールします。

無料の評価コピー(メディアISO)はこちらからダウンロードします。 GM1 と GM2 がありますが、インストールに必要なのは1枚め、二枚目はソースコードが入っています。x86_64、ppc、IBM、arch64 版それぞれがあります。

ダウンロードするためには、無料のアカウント登録が必要です。

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11042327.png
https://www.suse.com/download/sles/


正当なやり方であれば、光メディアにブートイメージを焼き込んで、ブートメディアからインストールを開始します。サブスクリプション登録したら、インストールソースは SUSE の最新リポジトリからコピーされます。当然インターネットの接続環境が必要です。最新版を使うには、サブスクリプション登録が必要なのですが、最終的なプロダクトネットワークにインストールせず、まずは動作確認のために配布メディアからインストールします

実際のサブスクリプションの購入はオンラインからも行うことができます。

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11053543.png



実際のサブスクリプション登録は SUSE Customer Center (SCC) で登録します。購入済で有効なサブスクリプションはここで確認できます。

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11064243.png



制限されたローカルネットワークでインストール

実際のテスト環境は隔離されたネットワーク環境なんだとか、インターネットの接続環境はそれほど良くないのですよ、という場合もあります。

また、データセンターなどで大量のサーバーをインストールするなら、SUSE には SMT という機能があり、多数のサブスクリプションを一括して管理できる機能もありますが、個人的には手が出せるものでもありません。インストールするサーバーが数台〜十数台であれば、わざわざ SMT をセットアップするほどでもないな、という場合もあるでしょう。でもインストールを少しでも楽にしたい。

Subscription Management Tool Guide

また、ベアメタルサーバーにインストールするケースは、よほどその筋の方ばかりでしょうが、偶にベアメタルハードウェアにインストールするのよ、と言う場合、まれにインストールの GUI が立ち上がらず、テキストインストーラになってしまって、ブートできても外部メディアからインストールできない場合があります。そう言った時も、手元に HTTP サーバーや FTP サーバがあると便利です。

という事で、SLE15 をローカルネットワークに用意したサーバからインストールする方法です。何台も、何度もインストールするには良いでしょう。



インストールソースを作る

ベアメタルサーバーを起動するには、USB メモリや DVD/BD ドライブに解凍したインストールイメージDVD.ISO が必要です。

起動だけです。

起動後、インストールソースを USB メモリなどのリムーバブルメディアからローカルネットワークにある、FTP,HTTP,SMB 上に展開した ImageDVD.ISO に切り替える事ができます。

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11085818.png

これにより、遅いインストールメディアから、高速なローカルネットワークのメディアに変更します。また、ブート後、USB デバイスは取り外しても構わないので、インストール後の YaST でのソフトウェア追加、削除するためにメディアの抜き差しが不要になるので、その後の作業は楽になります。

例えば HTTP サーバーから配布する場合

# mount -o loop SLE-15-SP5-Full-arc-GM-Media1.iso /srv/www/htdocs/instsrc

という感じでマウントしておきます。

Windows を使う場合、ISO ファイルを解凍した状態で、解凍先ディレクトリを SMB 共有させておきます。

14.6 サーバ上のインストールメディアのISOイメージの使用
https://documentation.suse.com/ja-jp/sles/15-GA/html/SLES-all/cha-deployment-instserver.html


実際のインストールの流れ


読むのが面倒な方は、全体の流れを動画でまとめてみました。音出ます。


次の様な流れです。

GM1-Media1.ISO でブートメディアで起動します。

ブートスクリーン
 > Installation

※ ここで、ブートパラメタを編集してリモートサーバーからインストールする方法もありますが、うまくいきませんでした。aarch64 だからかな?

言語とキーボードの選択
> ここでは英語を選択しました。後で日本語環境を追加でインストールします。
> キーボードは Japanese キーボード
> インストールプロダクト : SLES 15sp5
> License Agreement : Agree

Registration
> Skip Registration

※ ここでスキップしない場合、サブスクリプション登録の手続きになります。

Extension and Module Selection 拡張機能の選択
> uncheck ALL

Base Module と Server Application Modulle がデフォルトでチェックされ地ます。これを術て Uncheck します。ここでブートメディアから、ネットワークに用意した配布用のサーバーにインストールソースを切り替えます。


SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11112148.png


Continue ...

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11122121.png

リポジトリが空欄なので ”Add” ボタン



インストールソースを選ぶ事ができます。ここでは HTTP サーバを選びました。

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11124569.png


任意のリポジトリ名と配布元の FTP,HTTP,SMB などのアドレスを指定します。http://your_http_server/mount_pass

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11130986.png

再び拡張モジュールの選択画面が出てきます。ここで Base Module, Server Application Module と追加の拡張機能を選びます。ここでは Desktop Application Module と Legacy Module を追加してインストールします。

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11133382.png

これで、ブートメディアから、ローカルネットワーク内のサーバーにインストールソースを切り替える事ができました。インストール用のリポジトリがローカルのリソースに切り替わっています。

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11141084.png

System role (役割) を指定します

> ここでは、無難に SLES with GNOME でをチェックして YaST GUI と サブスクリプション登録に使う FIre Fox ブラウザが使える様にします。

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11135693.png

パーティション定義

> Default から、必要に応じて変更します。Expert Patitioner から Start with Current Proposal

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11144461.png

パーティションの編集画面です

※ よくある互換系ディストリビューションより細かくパーティションの設定ができます。個人的にはこのパーティショナーはよく出来ていて判りやすいと思うのですが如何でしょうか。

※ 互換ディストリビューションのパーティショナーより全然使いやすいとおもいますけどね。

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11150264.png

SLE15/openSUSE Leap15 では、システム(/)パーティションは BtrFS で、データパーティションは XFS がデフォルトです。

BtrFS でルートパーティションを構成する場合、スナップショットを使うので 30Gb 以上が推奨されます。将来マイナーアップデートが予想される場合を考慮して 60Gb程度はルートパーティションに割り当てると良いでしょう。ベアメタルサーバの場合、100 Gb 程度あれば長く使えそうです。また、この時点で空き領域を 100Gb 程度残しておくと将来何かあった時に役立ちます。

Clock と TimeZone の設定

> Asia/Japan を選びます。

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11155810.png

※ ここで Other Settings を開き、ローカルネットワークにある NTP サーバを選ぶことができます。デフォルトで SUSE のタイムサーバが選ばれているので、構内 NTP ソースや契約先 ISP のタイムソースに変更します。




ローカルユーザの作成

> 必要に応じて root 以外のユーザを作成します。スキップもできます。

root ユーザの作成

> root ユーザのパスワードをセットします。その際、特殊キーなどを使った場合のキーボードが正しく認識されているかを確認します


Installation Settings (インストールサマリ)

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11173091.png

ここでインストールに必要な詳細な設定を行います。

> Software : 追加するソフトウェア、例えば KVM ハイパーバイザーや、開発ツールなど、まずインストールしておきたいパッケージをここで追加します。

> Booting : ほぼデフォルトで問題ないでしょう

>Security : Firewall は有効、SSH は有効がデフォルトです

> Network : セットアップ方法はサーバー用途なので Wicked 、これは openSUSE Leap とは異なります。必要に応じて固定 IP やホスト名をここで設定します。

> Default Target : 起動後の GUI ログインか、テキストログインの方法をここで設定します。


ここで再設定できない root のパスワードやパーティション設定などは、この最終設定サマリから変更できないので Back ボタンで戻って再設定します。この段階でかなりh非常に細かな設定ができます。互換ディストリビューションの様に、後で面倒な設定をするのではなく、インストールする前に多くの詳細な重要で詳細な設定をここで行うことができます。

SUSE Linux Enterprise 15 (SLES15sp5) 評価環境にインストール_a0056607_11181070.png


ここで、Install ボタンを押すと、確認ダイアログが出てきてインストールが開始されます。確認ダイアログは、 「Back (戻る)」がデフォルトなので、誤って二度 Enter しても、よくある互換ディストリビューションの様にいきなりインストールが始まるようなことはないので安心です。


再起動

インストール後の設定

基本的なインストールをした後、最低限追加すべき標準的な作業として

・必要に応じて、デバイスドライバのコンパイルとインストール
・NTPの設定 (YaST)
・第二言語(Japanese) のインストール (YaST Language)


更にサブスクリプションを購入した後

・サブスクリプション登録とリポジトリのアップデート (YAST SCC)
・zypper dup あるいは YaST Online Update (YOU) で最新パッチのインストール

などがあります。ここまでが、サーバーインフラの構築手順です。


isLandcenter.jp



# by islandcenter | 2023-07-26 11:20 | SUSE | Comments(0)