皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

さて、Appleが2018年10月30日に行ったニューヨークでのイベント後、『iOS12.1』を正式リリースしました。

そして、そのiOS12.1には、会議としても使えるものが含まれています。

FaceTimeで32人までビデオ会議が可能に

今回の『iOS12.1』では、『iOS12』で延期となっていた『FaceTime』での『グループ通話』が可能になっており、以下のことを実現しています。

１．最大32人の参加者との同時ビデオ通話およびオーディオ通話に対応

２．エンドツーエンドの暗号化により会話のプライバシーを保護

また、使い方には2通りあるようで、

１．メッセージのグループチャットからグループFaceTimeを開始

２．FaceTime通話で1：1通話後に参加者を追加

といった感じになっています。

この『グループFaceTime』、ある意味では『ビデオ会議』にも使えるかと思います。

iPhoneだけでなく、グループFaceTimeの条件を満たしたiPadやMacを使えば簡単に『ビデオ会議』が行えます。

通信費的なところで言えば『データ通信』を使うことになりますので、Wi-Fi（無線LAN）が届かないところにいれば携帯の『パケット通信』を使いますが、社内などのWi-Fi（Macであれば有線LANでもOK）が整備されているところであれば携帯のパケットを消費することすらありません。

後は品質的にどうかということになるかと思いますが、1:1でのFaceTimeは悪くない品質でしたので、複数人での品質も期待したいところです。

日本にも、とんでもない数のサイバー攻撃を日々受けています。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

以前にも、『インターネットはサイバー戦争』という記事にて触れましたが、インターネットの世界をリアルタイムでモニタリングすると、すさまじい勢いで世界的にサイバー攻撃がなされています。

当然、日本に向けられたサイバー攻撃もとんでもない数になっています。

さて、ここで注目したいのは、一番攻撃を受けているのは何か？というところです。

23番ポートへの攻撃はNo.1

NICT（国立開発研究法人情報通信研究機構）のサイバーセキュリティ研究所が公開しているデータを見ると、昨年のダークネット観測パケット数の年間統計では、約1,281億ものパケットが観測されています。

そして、昨日のパケット数に目を向けると、No.1は23番ポートに対する8,108,510パケットで全体の37%も占めていました。

この23番ポートというのは、リモートメンテナンスなどの遠隔操作で使われる『telnet』用のポート番号で、暗号化されていない平文ベースの通信を行うものになります。

そこが一番狙われいているということです。

この『telnet:23番ポート』は、未だ多くのネットワーク機器においてメンテナンス用として残っていることが多いのですが、これは必要がなければ閉じてしまうべきです。

ただし、外部業者などから遠隔操作におけるメンテナンスを受けている場合は業者と協議せざるを得ません。

昨今のセキュリティソフトには、ネットワークに危険性があるのか否かを調査するツールがあったりもしますが、これはツールによって検知の仕方が異なりますので、それで問題がなかったからと言って絶対とは言えません。

現に、とあるメーカーのルータを確認したところ、A社のソフトでは問題が出ず、B社のソフトでは問題が発見されました。

このような場合においては、WAN側、LAN側、ともに23番ポートを内向きにすべてを拒否（廃棄）する設定を加えてあげなければポートは開いたままになりますので、万が一狙われてしまった場合においては被害を受ける可能性があるということになります。

そういったことにならないためにも今すぐ確認をし、やむを得ない理由がないのであればすぐに閉じてしまうことをお勧めします。

しかし、このセグメント分割に対して間違った認識をしている人もいます。

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

今日は、企業間の担当者同士にあった会話の中で耳を疑うような内容のものをご紹介します。

それはこんな内容です。

TCP/IP印刷に対する間違った認識

A氏：『新しく別のセグメントでネットワークを追加したのですが、そちらのセグメントにあるプリンタに印刷させてもらって良いでしょうか。』

B氏：『プリンタを使う分には構いませんが、TCP/IP印刷は同一セグメント内でしか印刷できないですよ。』

A氏：『いえ、別のセグメントに対しても印刷はできます。念のため社内でもテストをしてきましたので。』

B氏：『そんなことはあり得ませんよ。それは間違っていますね。』

A氏：『では、印刷の許可だけもらえれば結構です。』

こんな感じの会話なのですが、これはどちらが正解かというと、Aさんは正しくBさんは間違いです。

ちなみに、とあるプリンタを製造しているメーカーのサポートセンターのオペレーターもB氏と同じことを言っていたようなので驚きです。

別セグメントへのTCP/IP印刷

この会話が行われたところのネットワーク構成は下記のような構成です。

B氏構築のネットワークセグメント：192.168.1.0/24

同ルータLAN側IP：192.168.1.1（デフォルトゲートウェイ）

同セグメント内のプリンタIP：192.168.1.100

A氏構築のネットワークセグメント：192.168.2.0/24

同ルータWAN側IP：192.168.1.200、デフォルトゲートウェイとDNS IP：192.168.1.1

同ルータLAN側IP：192.168.11.1

同クライアント：DHCP自動取得

こんな感じのネットワーク構成になっているのですが、A氏が構築したネットワーククライアントからは下記のようにプリンタを設定します。

プリンタポートをStandard TCP/IPとし、プリンタのIPアドレスに192.168.1.100を設定します。

それ以外は、プロトコルでLPRを選択してLPRのキュー名を入れるか、Rawを選択してポート番号に9100などを設定するかです。

この設定で基本的には192.168.2.0のセグメントにあるクライアントから192.168.1.0のセグメントにあるプリンタ192.168.1.100に印刷を行うことができます。

もしこれで印刷できないとすれば、プリンタの置かれているセグメントにあるルータの設定としてプライバシーセパレート（ネットワーク分離）をしている可能性があります。

その場合はその機能をOFFにしないと印刷することができません。

ご参考までに。

さて、この真意は？

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

冒頭にお書きした内容は実際に起きた内容なのですが、こういった話しはよくあると言えばよくある話しです。

では、何故業者はこういった対応になるのでしょうか？

別セグメントのネットワーク

今回の事例では、元々A社が構築されていた業務システムネットワークに配慮し、別のセグメントにて構築するというものでした。

＜業務システム側のネットワーク＞

ルータ：192.168.10.1
サーバ：192.168.10.2（GW-192.168.10.1）
業務システムクライアント：192.168.10.3～5（GW-192.168.10.1）
事務クライアント：192.168.20.3～5（GW-192.168.20.1）

＜B社追加構築のネットワーク＞

無線LANルータ：WAN側-192.168.20.100（GW-192.168.20.1）/LAN側-192.168.30.1
クライアント：DHCP自動取得

簡単にはこんな感じなのですが、事務クライアントはアドレス変換にてルータを経由してインターネット回線に出ます。

また、B社追加構築のクライアントは、無線LANルータのWAN側である192.168.20.100からゲートウェイを通じて事務クライアントと同じ経路を経由してインターネット回線に出ます。

つまり、構成上から業務システムに与える影響はないのです。

もし可能性があるとしたら、事務クライアントも業務システムに影響を与える可能性を秘めていることになりますので、A社が主張したことは少々矛盾を感じます。

（A社も一般的には問題がないはずであることは認めていた。）

業者は自社以外のものを避けたがる

では、何故A社は業務システムへの責任を回避したかったのか？

よく、システム業者同士がサーバを分けて欲しい旨をクライアントに依頼することはあります。

単純に、どちらのシステムが問題で不具合が生じたのかの切り分けが難しく、相手方のシステムの問題であっても自社も調査をしなければいけない可能性を秘めているからです。

しかし、ネットワークの場合、別々に分断されたネットワークでは片方がインターネット回線を使用することができなくなってしまいますので、どこかでつなげておくしかありません。

そのためにセグメントを分け、影響が出ないようにしてつなげているわけです。

となると何故なのか？

私からすると、業務システム全体を把握できていないような気がします。

もし新しいネットワークの一部である無線LANルータを懸念しているのであれば、既に事務クライアントでも近い可能性はもっていますので、結局のところは全体を把握しきれていないと考えざるを得ないです。

もしくは、自分達が携わったもの以外による影響の可能性を残し、インシデント発生時の盾にしたいのではないかと思われます。

平たく言えば、問題が起きたら調査費用を請求したいということなのでしょう。

いずれにせよ、もう少しクライアントファーストである必要性があるのではないでしょうか。