検索:

送信ドメイン認証 – 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のライセンス再認証

WindowsServer2022の検証作業と移行作業が無事完了しました。
が…OSは問題なかったのですが、諸事情によりどうしてもあるサーバーの
OSを再インストールしなければならないことになりました。
お客様へのサービスには影響無いためそれほど急いでする作業ではありません。

とあまり緊迫感なく作業していたのですが、OSを別のサーバーで再インストール
したために画面右下に「…Windowsのライセンス認証を行ってください。」という
表示が出ます。もちろんライセンスは購入済みですのでライセンス認証を
実施したのですが…ダメです。何度やってもダメです。
おそらくハードウェアを変更したのが原因と思われます。
ハードウェアと言っても弊社のプライベートクラウド上にある仮想マシンです。

まずはGoogle大先生に聞いてみます。色々と解決方法を試したのですが、
どれもダメでした。次にマイクロソフト社のホームページでライセンスについて
調べてみます…昔から思っているのですがライセンスが非常に複雑です。
これを考えた人以外で理解している人はいるのでしょうかと思うくらいです。
ライセンスについての説明文を読んでも複雑過ぎて理解不能…という
より読む気になれません。そのうちに不安になってきました。購入したのに使えない…

ライセンス購入元へ問い合わせてみます。が…日本だと問い合わせてしてから
2~3日…遅くて1週間以上回答が無い場合があるのであまり期待出来ません。
ということでマイクロソフト社へ電話で直接問い合わせることにしました。
ホームページで問い合わせ電話番号を調べます。そこに電話すると…
「電話によるサポートは終了しました…」ん?え?
ライセンス認証終了していないのですが…

再度Google大先生で…今度はライセンス認証の電話番号を調べてみます。
ありました。早速電話です。番号を選択するようにとのガイダンスが
流れますので該当する番号を押していきますが…何度やっても人間様に
出ません何度もかけ直し押す番号を変えても機械様しか出てくれません。
格闘すること1時間…ようやく人間様が出てくれました。

電話サポートによると…まずサーバー上でコマンドを打ち込む…
すると数十桁の番号が表示されます。それを電話のボタンで入力することで
ライセンスが認証されるとのことです。慎重に番号を押していきます。
ようやく再認証されました。格闘すること2日間…非常に疲れました。
精神的に…


■ あとがき

WindowsServerのアップデート完了と安心していたら…次はLinuxです。
RockyLinux9のサポート期限2032/05/31…ただいまこれを検証中です。

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

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

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

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

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

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

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

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


■ あとがき

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

ランサムウェア感染拡大中

最近、日本企業の海外子会社がランサムウェアに感染したというニュースが
増えているような気がします。あるニュースでお客様の会社名が…
と思ったら弊社お客様の海外子会社でした。弊社は関与していないので
状況はわかりません。というニュースを見ていたら…なんと別のお客様から
メールが…ランサムウェアに感染したと連絡がありました。
緊急事態です。ですが、弊社が管理している上海のシステムではなく
弊社が関与していないお客様の兄弟会社のシステムとのことです。
サーバーが感染してしまいデーターが暗号化されてしまったとのことです。
しかもバックアップデーターも被害を受け途方に暮れているとのことです。

お客様が上海も感染するのではないかと大変心配されていて
至急ランサムウェアの感染防止対策をされたいとの連絡がありました。

まずは現状システムをどのように運用していてランサムウェア対策は
どのようにしているかということを説明しました。

・ファイアウォール(UTM)は弊社が常時監視している

・弊社のウィルスチェックサーバーでお客様のサーバーおよびPCの
ウィルスを監視している
・弊社のサーバーでお客様のサーバーおよびPCのWindowsUpdateを管理している
・お客様サーバーのバックアップは外付けのハードディスクで
毎日バックアップしている

お客様のPCがランサムウェアに感染するとPCからアクセス出来る
お客様のサーバーのデーターが暗号化されてしまいます。
さらにサーバーが感染するとバックアップデーターも暗号化されてしまう
可能性があります。

お客様のLANと弊社データセンターはVPNで接続されておりますので
緊急対策としてお客様のオフィスにあるサーバーのデーターを
弊社データセンターのサーバーへバックアップしました。
バックアップ完了後はお客様のLANから弊社データーセンターの
サーバーへはアクセス出来ない設定に戻しました。
これでランサムウェアに感染してもバックアップした時点のデーターは
守られます。

お客様のサーバーは導入からかなり経過していたので以前より更新を
提案しておりました。今あるサーバーを更新するだけの提案でしたが、
今回、ランサムウェア対策も考慮し下記のような提案も追加しました。

・サーバーはお客様のオフィスではなく弊社データーセンターにある
 プライベートクラウドへ移行。

・サーバーは2ヶ所のデーターセンターへ設置しデーターを同期

・サーバーデーターのバックアップのはサーバーOSからはアクセス出来ない
 プライベートクラウド上にスナップショットを作成

以上でランサムウェア対策は強化されます。
今回のサーバー更新とランサムウェア対策は、お客様の日本の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の申請です。これを申請しないと…