闇の魔術に対する防衛術Advent Calendar 2024

闇のような状況についての質問を平易に答える防衛術

Last updated at 2024-12-08Posted at 2024-12-08

質問について回答するお仕事、あんまり陽が当たらない闇

(ITな)エンジニアのお仕事ってどんなことがありますか？と聞かれれば

プログラミング
設計（サービス、UI、DB、ネットワーク）
基盤の構築/運用
テスト/QA

など、様々な内容が出てきます。

これら仕事の中に「（プロの）お客様から質問が来たら答える」という役割があります。あまり注目されないですね。「プロの」と限定しているのは、質問してくる方も仕事上の質問をする、答える方はサービスや製品の提供元として回答を行う、という範囲とするためです。（コールセンターで消費者からの質問に答える、は今回の範囲外です）

職種としては「テクニカルサポート」にあたると思います。しかし、IT関連のエンジニアお仕事をしていれば、回答の一部を考える、または、回答の依頼がエスカレーションされるなど、「質問に答える」ことは、どの役割でも求められます。

そんな日が当たらない割に重要な、仕事での回答のHowtoを書いてみました。

「質問に答える」の何が闇なの

お客様から質問が来たら答えることは

たまに錯綜とした質問が来て頭を抱える。
一定規模のサービスに携わっていれば質問は山のようにある、とにかく量が多い。
サービス・製品自体が優れていても、質問への回答が洗練されていなければ利用されづらい、そこを左右する重要な役割。
その割に注目されていない。

ここが闇です。

説明に使用する例

これから説明するにあたり錯綜とした内容の例を2つあげてみます（これらはフィクションです。いままであったものを適当に混ぜて改変しています）。

例① Tomcatのポートを8080から80にしたら、×× system が起動しなくなりました

「×× system」というシステムについて、お客様先に伺ってインストールを行った数日後に連絡がきた、という例です。

○○株式会社の△△です。

先日は貴社の ×× system の導入ありがとうございました。

×× system を Entra ID アプリケーションプロキシを通して、社外にいる弊社の従業員がアクセスする計画です。Entra ID アプリケーションプロキシで ×× system の内部URLとして http://××_system_server/ を使用したいのです。

あわせてインストールいただきました Apache Tomcat のポート番号 8080 を 80 に変更するにはどうしたらいいでしょうか。こちらで /opt/tomcat/conf/server.xml について

   <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />

を

   <Connector port="80" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />

と変更しました。

変更後、Tomcat を再起動し、×× system へ http://××_system_server/ へアクセスしたのですが画面の応答がありませんでした。ps コマンドで見るとTomcatのプロセスはありました。
/opt/tomcat/logs/catalina.out というファイルには

java.net.BindException: Permission denied <null>:80
    at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:549)
    at org.apache.tomcat.util.net.JIoEndpoint.start(JIoEndpoint.java:565)
    at org.apache.coyote.http11.Http11Protocol.start(Http11Protocol.java:203)

というエラーが記載されています。server.xml はいったん戻すと ×× system が稼働するようになりました。

よろしくお願いします。

以下では

質問者の用意したLinuxにインストールした
Apache Tomcat は「×× system」を動作させるために、この「×× system」インストールを行った回答者側が合わせてインストールした。HTTPのポート番号は 8080 とすることも含め、この点は事前にすり合わせ済みである。
「×× system」は、HTTPのポート番号を変えても、他の設定変更なく動作する。
Apache Tomcat は、root ユーザーではなく tomcat ユーザーで動作させている。（このためそのままでは 80 番ポートをTomcatは開くことができない。参考 https://linuc.org/study/column/5479/ ）
「Entra ID アプリケーションプロキシを通して、社外にいる弊社の従業員がアクセスする計画」は、回答者側にとって初耳である。

と仮定します。
「Entra ID アプリケーションプロキシ」は社内に設置するリバースプロキシで、これを設置すると、社外から社内のサーバーが公開できる、という優れものです（超ざっくり説明すみません）。

※ これちょっと分かりづらいので、後で構成図を追加します（2024/12/08 ふじた🐱）

例② 送信するメールが迷惑メールになりましたのでFromを変更することはできますか？

メールマガジン送信サービスを提供する会社に、利用者から質問が来た例です。

●●合同会社の▼▼です。

御社のメールマガジン送信サービスについてです。

先日問い合わせした、弊社から送信するメールマガジンが outlook.com あてで迷惑メールに判別されてしまう件、御社のサービスのせいではないようです。

ためしに◆◆社のサービスから弊社のメールマガジンを送信したところ、outlook.com に加えて、Gmail まで迷惑メールに判定されてしまいました。

そこで弊社の中で上長とも相談し、メールの送信者を「info@example.com」から「info@example.net」に変えたら、迷惑メールに判別されなくなるのではないか？というアイデアが出てきました。

一度実施したいのですが、メールの送信者ドメインを変えることはできますか。ドメインは弊社で取得します。

来週は土曜日に弊社がセミナーを予定しておりますので、そのメールを弊社のお客様全員に月曜日から金曜日、毎日送信する予定です。

以下では

このメールマガジン送信サービスでは、メールの送信者ドメインを、サービスの画面から変更することができる。
メールの送信ドメイン認証のためのDNS設定は、利用者が実施する。

と仮定します。

まず何が質問かを特定し、その質問に答えよう。

質問に答えるのだから、何が質問かなんて意識しなくていいのでは？と思いますよね。けれど、回答を作成していく中で、質問ではなくその周辺にある内容に答えてしまうこと、ありがちです。回答する際は、この文面の中で質問は何か？を必ず意識します。
（私はいまだに質問のメールを受け取ると、それをプリントアウトし、質問文に蛍光ペン引きます。物理です……）

質問は質問文とその補足から成り立っている

質問する人は、何か答えが欲しくて質問を送って来るわけですが、仕事上であれば、同時に質問の背景や直面した状況、問題といった付随する事柄をあわせて書いてくれることが多いです（それさえない場合、いますぐチャットを始めるか、そういうものがなければ、電話📞を握って根掘り葉掘り聞くしかありません）。

この質問と付随する事柄をまず区別しましょう。上の例2つではこうです。

-	質問	付随する情報
例①	Apache Tomcat のポート番号 8080 を 80 に変更するにはどうしたらよいか。	Entra ID アプリケーションプロキシを xx system で使用したい。(*1) 試したところエラーがでた。
例②	メールの送信者ドメインを変えることはできるか。	送信するメールマガジンが outlook.com あてで迷惑メールに判別されてしまう。他サービスを試したらもっとひどい目にあったので、御社サービスの問題ではない。(*2) 土曜日のセミナーのために月～金毎日メールを送る。

質問に答える人が、上の(*1)や(*2)について初耳であった場合、関心がそっちにいってしまうでしょう。気持ちとしては良く分かります。その結果、

当社の xx system と Entra ID アプリケーションプロキシを組み合わせた際に動作するかは保証しておりません。
当社で観測する限り outlook.com あてで迷惑メールに判別されてしまうことは少ないです。御社に由来する事項と存じます。

といった 質問に対する回答ではない回答 をしてしまうことは案外ありがちなのです（で、回答のレビュー担当がびっくりしたり、お客様に送って🔥フレームになったりする）。

また、回答者の経験が浅く、Linuxの制約を初めて知った場合

Linux では、現在 Apache Tomcat を動作させているユーザーは root ではない tomcat ユーザーですので、80 番に変更することはできません

と答えるケースもあるでしょう。これも下の答えにあるように、方法がありますので、答えとしては間違いです。

例①の質問に対する回答 は

設定ファイルの変更に加えて

Tomcatの実行ユーザーを tomcat から root にする。
iptables で 8080 に来た通信を 80 に REDIRECT する。

が必要、あたりです。まずこれが 回答に最低限必要な事項 です。そのほか手段にもあり https://ja.confluence.atlassian.com/confkb/permission-denied-error-when-binding-a-port-290750651.html によくまとまっています。

しかし、これらは

外部からアクセスされるプロセスが root で動作、セキュリティー上好ましくない
この方式になれてない組織で、この案を採用すると、構成変更時やトラブルシューティング時に意識されず嵌る

とおすすめできない事項なのです（特に1.）。また、付随する情報の「Entra ID アプリケーションプロキシ」の仕組みを調べれば（または知っていれば）この対応が不要なのです。

この点を踏まえた回答を、この後触れてゆきます。

例②の質問に対する回答 は、

回答者が提供するサービスでメールの送信者ドメインを変更することができるかどうか
メールの送信者ドメインを変更でき、ドメインが変わる場合、必要なSPF・DKIM・DMRAC の説明

が 回答に最低限必要な事項 です。

しかし、この質問者の本当の課題は「送信するメールマガジンが outlook.com あてで迷惑メールに判別されてしまうこと」でしょう。そのときにメールの送信者ドメインを変更することは悪手というか、してはいけないことなのです。

送ったメールが迷惑メールに振り分けられる要因はざっくり大きく2つに分かれます。（このテーマにまじで答えると超長いエントリができるのでそこは割愛）

1.送信する仕組みの問題（送信ドメイン認証、DNS、TLS など）
2.送信したメールが利用者にとって不要であったり不快であったりするケースが多い

いつも届いていたメールの送信者ドメインが急に変わったら、受信する人は困ります。例えば、日本の amazon から来るメールが xxx@amazon.co.jp から xxx@amznmail.com に変わったらと想像してください

どこから来たメールか受信者にとって分からない。迷惑メールか区別がつかない。
受信する人のメール振り分けのルールを変えないといけないかもしれない
携帯キャリアドメインならドメイン指定拒否やドメイン指定受信の変更が必要かもしれない

など色々困りますし、そういうことは不快ですよね。受信者が不快であることは「メールが開かれない」「迷惑メールとして報告された」といった受信するシステム（gmail,outlook.com,iCloud,yahoo!メール）の計測点を通して、迷惑メールと振り分けられる可能性をさらに高めます。

この点を踏まえた回答を、この後触れてゆきます。

○○できますか？には、○○はできます、コストは✖✖です、で答えよう

「○○できますか？」という質問、答えるには実は厄介なことが多いのです。

物理法則に反している
回答者の提供するサービスや製品の明確な制限に反している
コンプライアンスに反している

といったことでもない限り答えは「○○できます」です。ただ、その「○○できる」にはコスト(＋リスク)が伴うので、それを明示し 「○○はできます。××(お金,時間,もの,人)××かかります。」と回答しましょう。

この形、相手によっては、コスト(＋リスク)のことを忘れ「○○できる」が独り歩きすることもあります。リスクやコストを伝えていると後からお互いに分かるように口頭だけで伝えることは避けます。

してはいけないことは、コストが大きくて割に合わないと回答する側が判断し、「（○○もかかるので）××はできません」とすることです。 質問する側にとって「××できる」の価値が大きく「○○」というコストを払うことが順当であったとき、このような回答をすると「あの回答者は何を言ってるんだろう、できないという癖にできるのではないか？」となり、話が噛み合わなくなります。

この「○○はできます。××かかります。」と答えましょう、という話は「オレンジジューステスト」という名前で、G・M・ワインバーグの「コンサルタントの秘密」に載っています。

例①の質問に対する回答 にこの要素を加えると

先日導入した Apache Tomcat のHTTPポート変更について回答します。

Apache Tomcat のHTTPポートの設定は、ご指摘の server.xml の箇所でございます。

しかし、Linux では1023番以下の「Well Known Port」について、ポートを開く際
root 権限を必要とします。

現在、Apache Tomcat は root 権限を持たない tomcat ユーザーで動作させているため、80番ポートを開く権限がありません。
このため、「Permission denied」というエラーメッセージが表示され、設定ファイルの変更のみでは80番ポートを開くことができません。

Apache Tomcat を80番で開く方法としては、設定ファイルの変更にあわせて

Tomcatの実行ユーザーを tomcat から root にする。
iptables で 8080 に来た通信を 80 に REDIRECT する。

といった対応が必要です。

1.は外部からアクセスされるプロセスが root で動作しますため、セキュリティー上好ましくありません。
2.はこの構成を貴社でとられたことがない場合、今後、貴社にて「xx system」の稼働するLinuxのメンテナンスにおいて、戸惑われることがあると思います。

1.または2.を実施される場合、ご連絡ください。手順をお送りします。

といった回答ができあがります。「どうしたらいいですか？」が質問なので「こうするとできます。こういうコスト(リスク)が伴います」という形です。

例②の質問に対する回答 にこの要素を加えると

メールマガジン送信での送信者ドメイン変更について回答します。

メールの送信者はログイン後、○○の××メニューにある「送信者メールアドレス」画面から変更できます。貴社にて操作可能です。

送信者ドメイン変更に合わせ、メール送信ドメイン認証（SPF・DKIM・DMRAC）を設定することも必要です。
この点、送信者ドメインを変更するにあたっては計画いただき実施をお願いします。

また、事前に受信者への案内なくメールの送信者を変更しますと、受信される方が貴社から来たメールなのか分かりづらくなることなどから迷惑メールに判定される確率が高まります。

といった回答ができあがります。「できますか？」が質問なので「できますよ。けれど、こういう手間やリスクが伴います」という形です。

(もしあれば・もし分かれば)本当の課題を支援しよう

ここまで読んできた方には

例の①なら、Tomcatのポートを変更するのではなくて、「Entra ID アプリケーションプロキシ」の内部URLを変更すればいいと伝えれば、そんな長々とした説明は不要で一発じゃないか
例の②なら、迷惑メールに振り分けられる率の増加も含め、送信者ドメイン変えるなんてダメと伝えれば一発じゃないか。
例の②に付け足せば、そもそもセミナーの案内、毎日送るなよ。そういうメール送信の頻度が高くて受信者の不快を招くことがが迷惑メールに判定される原因だよ。

と感じる方いると思います。では、こちらを先に伝えるとどうなるか、体感6割方「質問と違う回答がきました、答えてください」とか「それはわかるのですが、後学のためにも私の質問に回答してください」と不評を受けるのです。

本当に伝える必要があることが「『Entra ID アプリケーションプロキシ』の内部URLを変更」「送信者ドメイン変えるなんてダメ」「そんな頻度高くおくってもダメ」であっても、質問する側は回答を受け取ったとき、自分の質問の回答から探します。それがないと不満に感じ、質問者の本当の課題に関する答えすらスルーされたり軽視されたりするのです。

このため、この例のような本当の課題が明確に分かっている場合でも、

まず質問を見出して、その質問になるべく中立的に答える
その後に「本当の課題」に対することを書く

と構成しましょう。では、この1.と2.を書く際に何に気を付けるか、それが次の項です。

英語の助動詞のような動詞を使い分けよう

英語の助動詞で「MUST、SHOULD、MAY」ってありますよね。

まず質問を見出して、その質問になるべく中立的に答える

その後に「本当の課題」に対することを書く

の1.は質問に対し、事実を提示する形が多いので、～～です、と書き手（回答者・回答する組織）の主観が入る余地が少ないです。2.は踏み込んだ答えになり、課題の解決にあたり質問者しかしらない制約などあり得ることを想定し、回答者の気持ちや判断を表すために、英語の助動詞のような動詞をうまく使って書きましょう。

使うのはこのあたりでしょうか。

○○をお願いします（依頼）
○○を推奨します（意見の表明）
○○と予測します（未来の予測を伝える）
○○と判断します（決定した考えの表明）
○○と推測します（判断までは至らない考えの表明）
○○と聞いています（伝聞）
○○と言われております（一般的な事項の伝達）

いかにもITエンジニアの書いた文章になりますが、大事なことが、回答者の意図が質問者に伝わることです。

例の①は、「Entra ID アプリケーションプロキシ」の内部URLを変更することを依頼したい
例の②は、「送信者ドメイン変える」ことは推奨しない
例の②は、「メール送信の頻度が高いと迷惑メールに判定される」から見直すことを依頼したい

といったことが回答に付け加えたいことです。というわけで最終的にできあがった回答はこうなります。

例①だと……

先日導入した Apache Tomcat のHTTPポート変更について回答します。

Apache Tomcat のHTTPポートの設定は、ご指摘の server.xml の箇所でございます。

しかし、Linux では1023番以下の「Well Known Port」について、ポートを開く際
root 権限を必要とします。

Apache Tomcat を80番で開く方法としては、設定ファイルの変更にあわせて

Tomcatの実行ユーザーを tomcat から root にする。
iptables で 8080 に来た通信を 80 に REDIRECT する。

といった対応が必要です。

1.または2.を実施される場合、ご連絡ください。手順をお送りします。

また、メールを拝見し、「Entra ID アプリケーションプロキシ」からのリバースプロキシと理解しました。この場合、「Entra ID アプリケーションプロキシ」の内部URL変更による対応も検討をお願いします。

現在、内部URLは http://xx_system_server/ を設定されていると思います。ここを http://xx_system_server:8080/ と変更します。あわせて「Entra ID アプリケーションプロキシ」から xx_system_server への 8080 への通信が通るよう貴社ネットワークの設定が必要です。
こちらで社外から xx system が見られるようになれば、上記のApache Tomcat を80番で開く対応は不要でございます。当社としては、内部URL変更による対応を推奨いたします。

例②だと……

メールマガジン送信での送信者ドメイン変更について回答します。

メールの送信者はログイン後、○○の××メニューにある「送信者メールアドレス」画面から変更できます。貴社にて操作可能です。

しかし、事前に受信者への案内なくメールの送信者を変更しますと、受信される方が貴社から来たメールなのか分かりづらくなることなどから迷惑メールに判定される確率が高まると予測します。

このため、貴社でお困りである迷惑メールに判定される可能性をより高めてしまいます。弊社としては送信者ドメインを変更しないことを推奨いたします。

メールに記載された、セミナーの案内を毎日送信するという頻度は、迷惑メールに判定される可能性を高めていると推測します。
受信する方にとって毎日同じテーマのメールが来ることは、迷惑メールの報告を招き、開封率も下がることから、ご質問にあった outlook.com をはじめ、メールを受信するシステムが、迷惑メールと判定しがちになります。

迷惑メールに判定されることを改善するには、送信する内容や頻度に関しての見直しをお願いします。

実際、ここまで助動詞っぽい「○○する」を使う文面はまれですが、分かりやすいので作ってみました。

今回も長くなってしまいました。うーん、文章を短くまとめるのは難しい。指摘あればコメントやTwittwerなどでご指摘いただけると幸いです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up