検索:

送信ドメイン認証 – DMARCへの対応

スパムメール、ゴミメール、なりすましメール等々….
迷惑メールが毎日届きます。ただしほどんどの迷惑メールは受信ボックスへ
配信される前にスパム対策のメールゲートウェイによって拒否および隔離
されていると思います。
SPF,DKIM…昔から様々な対策が導入されております。
今はメールはクラウドを利用されている企業様がほどんどだと思いますが、
最近、クラウド事業者から「DMARCへ対応してください」という連絡は
ありませんでしょうか?

DMARCとは簡単に言えば迷惑メール対策です。
DMARCを導入するにあたり「SPF」と「DKIM」を導入する必要があります。

【SPF(Sender Policy Framework)】
ドメインを管理しているDNSサーバーにメールサーバーの
IPアドレスを登録し公開します。相手側メールサーバーがメールを
受信する際、送信元ドメインのメールサーバーのIPアドレスが
公開されているものと一致するか確認するという仕組みです。

【DKIM(DomainKeys Identified Mail)】
公開鍵暗号技術を利用します。送信するメールに「秘密鍵」で作成した
電子署名を追加します。相手側メールサーバが受信する際、
DNSサーバーで公開されいる「公開鍵」で電子署名を検証することで
電子署名の作成者の身元が確認出来ます。
さらにメールデーターの改竄も検知することが出来ます。

【DMARC (Domain-based Message Authentication Reporting and Conformance】
「SPF」と「DKIM」の検証結果により受信側がメールの扱いをどうするか
決める仕組みです。ドメインを管理しているDNSサーバーで
DMARCレコードとして公開します。

クラウドを利用されている企業様はWebの管理画面でDNSレコードを管理
していると思いますが、DMARCへの対応もWebの管理画面から
公開鍵、秘密鍵を作成しDNSレコードで公開という方法になるかと思います。
クラウド事業者によって方法が色々ですのでDNSとメールの仕組みを
理解していないとDMARCへの対応が難しいかもしれません。
お困りであればご相談ください。


■ あとがき

2024年2月からGmailがSPF/DKIM/DMARCに対応していないドメインからの
メールを一日5000件までに受信が制限されております。
今後はGmail以外にもGoogle WorkspaceやOffice365も同様に
制限されるかもしませんので早めに対応を!

Windows Server 2012/2012 R2 サポート終了

10年以上という長期にわたって提供されていた WindowsServer2012/2012R2の
サポートが2023年10月10日に終了します。

思えばその昔…最初にファイルサーバーを構築した時に使用したOSは
Novellというメーカーの「NetWare 3.12」でした。その次が「NetWare 4.11」です。
オフィスの片隅にサーバルームというパーティションで囲んだだけの部屋がありました。
そこに業務用フリーザーみたいな物体がありました…それがファイルサーバーでした。
その時代..オフィスでは「緊急事態発生!サーバーが落ちた!何とかしろ!」という
怒号が飛び交うことがありました。ファイルサーバー停止=業務停止という
ことになりそれはもう大騒ぎでした。原因で多かったのは熱暴走だったと思います。
業務用フリーザー…でなくファイルサーバーの前には扇風機が何の違和感もなく
鎮座している時代でした。

Microsoft社がWindowsNT Server 3.51を発売したころには
NetWareから移行する事が多くなりなした。
そのころは…Microsoft社がサーバーOS?なんて時代でした。
とにかく不安定でWindowsNT Serverは毎日起動する…というのか私の周りでは常識でした。

WindowsNT Serverのサーバーの落ち方も豪快です。
突然サーバーに接続されているモニターがブルー画面になります。
そこに白い文字で英語のような長い呪文が表示されます。よく読むと最後に
「管理者に連絡しなさい…」という指示が表示されています。そこで管理者を
探すため周囲を見渡し…ん?あれ?もしかして自分?ということが判明し
私の顔面がブルーになった思い出があります。
それがトラウマとなり今でもマ○クロソフト社のサーバOSは嫌いです。
サーバーOSは安心のLinuxが私のデフォルトです。

前置きが長くなりましたが…その後
WindowsNT Server 3.51
WindowsNT Server 4.0
Windows2000 Server
WindowsServer 2003/2003R2
無かったことにして…
WindowsServer 2012/2012/R2
無かったことにして…
WindowsServer2022
というようにファイルサーバーのOSをアップデートしてきました。
20年前からは10年毎にアップデートというパターンです。
WindowsServerの基本的な機能しか必要無いのでセキュリーティーパッチが
提供されいれば十分です。

まずは試用版のWindowsServer2022をダウンロードして色々と基本的な
機能が問題無いことを確認です。

その後ActiveDirectoryにWindowsServer2022を追加して2012R2と混在し
問題なく稼働することを確認です。

弊社は日本と中国のデーターセンターにファイルサーバーがあります。
日中間でファイルサーバーのデーターを複製し同期しております。
そこにWindowsServer2022のファイルサーバーを追加してデーターを同期
出来ることを確認です。

最後にWindowsServer 2012R2を停止して移行完了…
ライセンを購入して認証もお忘れなく…


■ あとがき

移行中はWindowsServer 2012R2と2022が混在させた状態で安定稼働を
確認し慎重に移行作業を実施しました。
私失敗しないんです…というのはこの業界ではありえないので
私失敗しても大丈夫なんです…という状況にするのが基本です。

ランサムウェア対策サービス

IT系のニュースサイトでランサムウェア被害のニュースがさらに
増えているように思えます。

弊社ホームページに「ランサムウェア対策」サービスを追加しました。
https://www.evolutionnetworks.net/service/ransomware.html

ランサムウェアに感染すると重要なデーターがロックされに
アクセス出来なくなります。データーを適切な方法でバックアップし、
OSやウィルス対策ソフトのウィルス定義ファイルを最新の状態にする。
さらにUTMやサーバーを常時監視することで感染リスクやダメージを
最小限にするサービスです。

【データーを複数のデーターセンターへバックアップ】

例えランサムウェアに感染しファイルが開けなくなっても
バックアップデーターが感染していなければバックアップを
取得した時点までは復旧可能です。ただしバックアップ先が
お客様のサーバーに接続されているハードディスクやPCなどの
端末からアクセス出来る環境ではバックアップデーターまで
感染するリスクがあります。そこでお客様のサーバー以外からは
アクセス出来ない遠隔地のデーターセンターにある
プライベート・クラウドにデーターを複製することで対策をします。
さらにお客様のサーバーからアクセス出来ない別のデーターセンターへ
複製しプライベート・クラウド上でスナップショットを取得することで
データーを保護します。

【WindowsUpdateとウィルス対策】

ランサムウェアに感染するリスクを下げるためにはお客様の
サーバーやPCのOSとウィルス対策ソフトのウィルス定義ファイルが
最新である必要があります。これらの対策に必要なサーバーを
すべてデータセンターのプライベート・クラウドにあるサーバーから
サービスを提供します。

【稼働状況とトラフィックの監視】

ランサムウェアに感染した場合、いかに早く対応し被害の拡大を
抑えるかが重要です。UTMやサーバーを常時監視することで
通常とは違う状況に早く気がつくことで対策します。
例えばCPUの使用率状況や回線使用率の急上昇などに
気がつけば被害の拡大を抑えられる可能性があります。


■ あとがき

日本では未だに「インターネットVPNは危ない」
「バックアップはローカルで取得する」という方針の企業があると聞いて
驚いております。ほんの一部の企業とは思いますが…

コロナ禍でのハードウェア更新

新型コロナウィルス感染症により中国出張が非常に難しくなってから
早2年以上となりました。今、私は日本におります。中国のデーターセンター
にある弊社サーバーの更新作業…出張しようと色々調査しましたが
リスクが高いので断念しました。ということでフルリモートで対応することに
なりました。

まずは購入するスペックを決め現地スタッフに発注を依頼します。
すると数時間で見積もりが届きます。日本のように数日、数週間、数ヶ月
かかるということはありません。ですが、発注しようとすると
お約束で「今在庫がない」「それは生産停止になりました」ということが
90%以上の確率で発生します。ですのでこれを考慮し予め様々なスペックを
考えておきます。納期もコロナ禍のロックダウンで輸送が大幅に遅れる
ことを考慮する必要があります。

ハードウェアが納品されたらまずは開封作業です。その前に既に箱が
開封済でないことを確認する必要があります。
オプションのメモリやハードディスクなどは別のサーバーから取って来た物を
納品されるということが良くあるので、箱に入っていて開封済みでないことを
確認する必要があります。

機器の設定はリモートから実施します。現地スタッフに購入した機器を
オフィスのLANに接続してもらいます。そして初期設定情報が書かれた
資料を送ってもらいます。情報がそろえば日本からリモートで
接続しOSのインストールです。弊社の日中間ネットワークは
常時数十Mbpsでているのでインストールはストレスなく作業出来ます。

サーバーの設定作業完了後、機器をデーターセンターに搬入です。
コロナ禍ですので入館手続きに時間がかかります。
特にこれから10月にかけ北京で会議があるので、データーセンターに
機器を搬入出来なくなる時期があり注意が必要です。

これで作業は完了です。リモートでも簡単にハードウェアの更新が
出来ます…というのは弊社が20年近くの実績があるからです。
日本のIT部門が中国のIT部門に依頼する場合、言語や文化の違いによる
意思疎通がうまくいかない場合があります。中国に日本語が出来る通訳が
いてもITの知識が無いとこちらがやりたい事を伝えるのが非常に困難です。


■ あとがき

前回、書いたようにランサムウェアの感染が拡大しております。
ハードウェアの更新だけでなくセキュリティー対策の強化など
中国の現地企業のITでお困りであればご相談ください。
日本語で対応し(私が)中国では現地スタッフが対応します。

CloudStackの導入 – 動作確認・移行編

前回のノードサーバー編ではLinux上にCloudStackのエージェントソフトをインストールし

CloudStackにノードサーバーを追加しました。さらに仮想サーバーを停止することなく

移動することが出来るライブマイグレーションについて書きました。
今回は最終回…動作確認・移行についてです。

CloudStackが完成したのでいよいよ仮想サーバーを作成します。
と…その前にVLANを作成します。例えば、192.168.0.xxx/24や172.16.0.xxx/24というVLANを

用途毎に作成します。

仮想サーバーをゼロから作成するためにLinuxやWindowsのイメージファイル(iso)をCloudStackに

アップロードします。それから仮想サーバーに作成時にisoファイルをマウントするようにして
OSをインストールします。

仮想サーバーが出来れば、サーバーを停止してCPUやメモリを増強し正常に稼働し増強出来ているか

確認します。さらに仮想サーバーを稼働させたまま他のノードサーバーへライブマイグレーションが

正常に機能するかも確認します。

仮想サーバーの動作確認が出来れば…次は仮想サーバーにいつもインストールするツールなど

インストールして標準となる仮想サーバーを作成します。それをCloudStackへテンプレートとして
登録します。次回よりテンプレートから仮想サーバーを作成することでOSやツールを

インストールする時間を大幅にが短縮出来ます。

次に既に仮想している旧CloudStack環境からの移行です。今回弊社では新旧はまったく別の

環境として構築しましたので仮想サーバーを稼働しながらのライブマイグレーションは出来ません。
まずは旧CloudStack環境で稼働している仮想サーバーを停止してOSやデーターを移行作業用のPCに

ダウンロードします。それを新しいCloudStack環境にテンプレートやデーターとしてアップロードし…

テンプレートから仮想サーバーを起動することで移行出来ます。ファイルのサイズが数十GB以上ありますので
移行には稼働しているシステムへの影響を最小限にするために数週間から数ヶ月かかります。

最後はZabbixやNagiosなどの監視ツールに設定を追加して作業は無事完了です。


■ あとがき

今回、新しいCloudStack環境への移行作業は、新バージョンのCloudStackを
検証したりサーバーをリプレースするなどの作業があり半年以上かかりました。
ハードウェアの交換などは現地のスタッフが作業しましたので私は一度もデーターセンターへは

行っておりません。すべてリモートワークで完結しました。

CloudStackの導入 – ノードサーバー編

前回のクラウドコントローラー編ではLinux上に管理サーバーとデータベースサーバーをインストールし

ブラウザから管理画面にアクセスしCloudStackでインフラを構築出来る事について書きました。
今回はノードサーバーの導入についてです。

ノードサーバーとはCloudStackで作成する仮想サーバー、仮想ルーター、仮想スィッチに

CPUとメモリなどのリソースを提供するサーバーです。

ノードサーバーはハイパーバイザー(仮想サーバーを動かすソフトウェア)です。
Hyper-V、KVM、VMware、XenServerなどが利用出来ます。弊社ではKVMを使用しております。

KVM(Kernel-based Virtual Machine)とはその名のとおりLinuxカーネルをハイパーバイザとして

機能させるための仮想化モジュールでLinuxに組み込まれたオープンソースの仮想化テクノロジーです。

ようするにKVM を使用すると、Linux がハイパーバイザーになります。

ノードサーバーの構築は簡単です。LinuxをインストールしてCloudStackのエージェントソフトを

インストールする…後はCloudStackの管理画面でノードサーバーを追加するだけです。

CloudStackが非常に便利なのは…CPUやメモリなどが不足したら新しい物理サーバーを購入し

ノードサーバーとして設定しCloudStackの管理画面で追加すれば増強出来ます。
さらに…古くなったノードサーバーから新しく追加したノードサーバーへ仮想サーバーを

停止することなく移動することが出来ます。これはライブマイグレーションという機能です。

これだけでもCloudStackを導入するメリットがあります。


■ あとがき

初めてライブマイグレーションした時はちょと感動しました。物理サーバーではありえない機能です。

CloudStackの導入 – クラウドコントローラー編

前回のストレージ編ではNFSサーバーの導入について書きました。
今回はクラウドコントローラーの導入についてです。

ネットワーク構築やストレージサーバー導入まではCloudStackに特化せず一般的な話しでしたが、

今回からはCloudStackのソフトウェア導入の話しになります。

まずはLinuxをインストールするハードウェアですが、以前は物理サーバーにインストールしておりましたが、

今はハイパーバイザー(仮想サーバー動かすソフトウェア)上にインストールしてあります。
CloudStackで使用しているハイパーバイザーとは別のソフトウェアを使用しております。

CloudStack上で稼働している仮想サーバーのバックアップサーバーもこちらで稼働させていますので
最悪CloudStackがすべて停止してもサービスは継続出来るような構成にしております。

クラウドコントローラーとはストレージサーバーやハイパーバイザーをリモートから操作するものです。

仮想サーバーに割り当てるストレージを作成しCPUやメモリを割り振って仮想サーバーを作成する機能や
仮想ルーターや仮想スィッチを作成しVLANを作成するなどです。

クラウドコントローラーに使用するOSはLinuxです。そこにCloudStackの管理サーバーと設定情報を

格納するデーターベースをインストールすることでCloudStackのクラウドコントローラーが作成出来ます。
どちらもNFSサーバーと同様にサーバー2台を1セットとしてデーターを常時複製し冗長化しております。

クラウドコントローラーが作成出来ればいよいよCloudStackの設定です。

<ゾーン>
データーセンターのようなものです。地理的に離れたデーターセンターを複数利用しているのであれば
それぞれのゾーンを作成することになります。

<ポッド>
データーセンターのラックというイメージです。複数のラックが追加出来ます。

<クラスター>
ポッドに追加するものです。クラスターには次回の号で書くCPUやメモリなど提供するノードサーバーを

追加します。

<プライマスストレージ>
OSやデーターを格納する場所です。

<セカンダリストレージ>
ISOイメージファイルやOSのテンプレートを格納する場所です。

他にも初期設定として物理ネットワーク、共用トラフィック
ゲストトラフィックなどを設定します。

CloudStackの管理画面は多言語対応されております。機能もわかりやすくマニュアルも整っておりますので
やる気と根気があれば時間がかかりますが習得出来ます。


■ あとがき

ブラウザ上でインフラが構築出来る…パブリッククラウドでは当然ですが、
それを自社のインフラでも構築出来るCloudStack最高です。

CloudStackの導入 – ストレージ編

前回のネットワーク編ではインターネット回線やVLANの設定などについて書きました。

今回はストレージの導入についてです。

ストレージと言っても規模により様々製品や技術があります。
CloudStackではNFS,iSCSIなど様々なファイル共有システムをサポートしておりますが、

弊社ではNFSを使用しております。

CloudStackで使用するストレージにはOS、データーなどすべての情報が格納されるので

これが停止すると仮想サーバーが全部停止してしまいパニックになること間違い無しです。

安定稼働と障害対策が非常に重要です。

NFSサーバーとしてはメーカー製のストレージ専用サーバーがあります。
規模にもよりますが、製品本体はもちろんサポートサービスも非常に高価であります。

特に障害発生の緊急事態時に自社で対応出来ないのは不安です。特に中国では不安です。

問題無い…で終わってしまっては非常に困ります。死活問題になります。

もちろん中国の代理店によってはサポートのレベルが非常に良い会社もあります。

日本だとメーカーのサポートは良いのですが、他社のサポート担当者のデーターセンター入館手続きで

申請した名前の一文字が身分証明書と違うとか…パーツの型番が1文字違うなどで再申請のループとなり
復旧まで時間がかかるという落とし穴があります。

弊社ではNFSサーバーとして…ハードウェアはメーカー製の汎用サーバーを使用しております。

もちろんRAID構成です。さらにサーバー2台を1セットとしてデーターを常時複製し冗長化しており

サーバーが1台故障しても停止時間は最小限になるように設計しております。
OSはLinuxでデーターを複製するソフトウェアはオープンソースを使用しておりますので

障害発生時は自社でほぼ対応可能です。ストレージサーバーが設定出来たら最後はディスク速度の計測です。
ハードウェアの導入時期やRAID構成によってスピードはかなり違います。

CloudStackの機能としてディスク容量の増加やデーターを別のストレージへ移動することが管理画面で

簡単に出来ます。これは非常に便利です。新しいストレージサーバーを導入した場合、仮想サーバーを

停止する必要はありますが、管理画面で数クリックすることで移動出来ます。


■ あとがき

Linuxとオープンソースのソフトウェアで冗長化されたNFSサーバーを10年以上使用しておりますが、

非常に安定しております。何と言っても…精神的に安定です。

CloudStackの導入 – ネットワーク編

前回の準備編ではデータセンターの選定について書きました。今回はネットワークについてです。

インターネット回線…帯域やグローバルIPアドレスの個数を決めます。
日本ですと希望どおりのサービスが安定して受けられますが、中国ではそう簡単にはいきません。

特に海外との通信に問題のある回線があります。導入後も国による規制などに対応しなければなりません。
事前連絡がなく突然特定のIPアドレスの特定のポートが閉じられることもあります…

これを書くときりがないので過去の記事をご参照ください。

UTM(統合脅威管理)…ルーティングやファイアウォール、VPNなどに弊社では米国メーカーの製品を

導入しております。日本と中国で安定して購入出来る製品を選んでおります。

Switch(スィッチングハブ)も同じく米国メーカーです。

インターネット回線が準備出来たら…ラックにUTMとSwitchをマウントしLANケーブルを配線をします。

その前にインターネット回線が正常に通信出来るか確認する必要があります。

以前、中国で経験したのはLANケーブルを接続した途端に物凄い攻撃を受けたり…非常に通信が
不安定だったり色々問題を経験しました。

通信の正常が確認出来たらCloudStack用にSwitchのVLANを設定します。

管理・監視、ストレージ、サービス用にそれぞれVLANを設定します。
後で変更するのは大変なのでここでの設計・設定が重要です。

これでネットワーク構築が終了と思われますが、一番重要な作業があります。
ネットワークが安定するか確認です。ラック内のLANとラック外のネットワークに監視サーバーを

設置し1週間程度…遅延、パケットロス、通信速度等の統計を取ります。
ある曜日のある時間帯に通信が異常に増えたり海外からの通信経路が
おかしいなどあるかもしれません。監視サーバーで統計を取得しているとトラブル対応の

手助けになるかと思います。中国でトラブル時に電話で問い合わせても…「問題無い」で

終了してしまいます。その時に遅延やパケットロスの統計情報があれば資料を作成し送付することで

もしかして対応してくれるかもしれません。


■ あとがき

メールサーバー構築するのであればDNSの逆引きの対応も必要です。
そして際も重要なのが中国で必要な手続きであるICPの申請です。これを申請しないと…

CloudStackの導入 – 準備編

弊社ではデーターセンターにあるプライベートクラウドにオープンソースの

クラウド基盤ソフトウェアであるCloudStack(クラウドスタック)を利用しております。
AWS,Azure,GoogleCloudなどにある…ブラウザ上で数クリックするとサーバーが

出来るというサービスを自社のインフラで実現出来るものです。

弊社では日本と中国の複数箇所でラックを借りており7年程前からCloudStackが

稼働しておりますが、クラウド基盤が動いているOSのサポート期限が切れるので
今回はOSの再インストール作業になります。ついでにCloudStackも新しいバージョンへ移行します。

今回より何も無い状況からCloudStackを導入する場合の手順について数回に分けて書いていきます。

まずはデーターセンターの選定です。日本ですとどこを選んでも大きな失敗はしないと思いますが、

問題は中国側です。立派な建屋から…ここに本当にデーターセンターがあるの?…というような

外観の建屋など色々あります。外観は妥協するにしても電源とネットワークが安定していることが

最重要事項です。できればセキュリティーがちゃんとしていれば安心です。

電源設備…UPSや発電設備など素人が見てもわかりません。

ネットワークも同じく帯域などスペックだけではわかりません。
結局、実際にシステムを導入して数ヶ月~1年ほどしないと状況がわかりません。

トラブルは100%発生するのでどこまで障害の影響を抑えるかになります。

日々システムを運用していくにあたり中国では技術的なことはもちろんですが、
通信会社やデータセンター側との交渉が非常に重要です。
会社設立から20年…色々とありえないトラブルを経験しました。
詳細については過去の記事をご参照ください。


■ あとがき

システムを導入する場合、まずはパブリッククラウドを選ぶのが一般的になった今、自社で

ハードウェアを保有する必要があるのかと思われるかもしれませんが、

中国では自社でコントロール出来るのであればそれに越したことはありません。

今まで…えらい目にあってきた経験者談です。