私はサポートエンジニアになりたい

元教師・現開発エンジニアの挑戦

2021年度に取り組んだことを振り返る

サポートエンジニア 私について

この1年で何ができるようになったか振り返る回

1年前の自分と比べて、私はできることが明らかに増えていた！

技術

  • Pyhtonを使ったWebアプリケーションの開発
  • C#を使ったデスクトップアプリケーションの開発
  • Microsoft SQL ServerとVB.NETを用いた生産管理システムの改修
  • 納品した実行ファイルと同じソースコードが存在しない中、不具合改修と機能追加を実施
  • ソースコードから稼働中のシステムのボトルネックを特定し、次期改修案件として仕事を受注
  • 改修したコードを本番環境にデプロイ
  • チームで本番環境のトラブルシューティング
  • ユーザーから不具合をヒアリング・原因調査と対応

などなど。

この1年は、今までやったことのない技術にふれる機会が多かった。

いい意味で自分の殻をやぶることができた気がします。

初めて扱うプログラミング言語や技術に対して戸惑いながらも調べたり質問したりすることで何とか乗り切ることができる！(というより、何事も挑戦しないと自分が成長できない)

今もガントチャートとにらめっこしながらプロジェクトを遂行して開発職を楽しんでいます。

ユーザーの声を聞いて、不具合の現象を確認しトラブルシューティングする。これはこれで楽しい。仮説があたったときはうれしいですし、仮説がことごとくはずれたときに先輩エンジニアさんに相談すると、先輩流のトラブルシューティング(秘伝のたれ)が垣間見れて非常に勉強になる。

「ユーザーがシステムを操作するうえでは問題はないと判明したから調査は終了するけど、なんでこの現象起きたの？」というものに出会うと、ちょっと悔しい。

こんな感じで、トラブルシューティングは私の感情をゆさぶってきます！

資格

4月の応用情報技術者試験が終了次第、資格の勉強はストップします。

というのも、時間は有限だからです。

忘れないための勉強と傾向を把握するための勉強にかける時間が惜しい。それよりももっと学ぶべきことがあるのでは？と思ったのです。

たとえば、(私とお話しした)サポートエンジニアの方が重視していたTCP/IP・OS・Webの仕組みあたりは理解して説明できるようになっておきたい。

ITというものは範囲がとても広い。だから同じことを何度も繰り返すことよりも知らないジャンルの知識をつけたり学んだことを深めることが市場価値を上げるうえで大事なのでは。

その他

  • Linkedinに職務経歴をまとめる
  • サポートエンジニアに興味を持つ
  • サポートエンジニアのカジュアル面談をする
  • 本選考に進めず
  • 学習欲に火が付く
  • このブログをはじめる
  • ツイッターに1週間を振り返るようになる

チャンスに気づいたら、いつでもチャンスをつかめるように。そしてチャンスをつかみそこなうことがないように。

そのためにも常にアンテナを張り準備をし続けたい。

来年度の目標

健康で文化的な生活を送るエンジニアであり続けたい！

燃え尽きない程度に業務で力と成果を出し、社内・社外で活躍できるように今日も明日もちょっとずつ前進していくぞ！

そして、サポートエンジニアを目指す。今度こそ

私だって偶然をキャリアに活かしたい！では、そのために何をする？

書評 サポートエンジニア 私について

そう、読んだだけで終わりにするのはモッタイナイと思ったのです。

アマゾンのリンク：https://www.amazon.co.jp/dp/B09VLHHVQD

5つの行動特性とは

好奇心：興味を持ったことには取り組んでみる

持続性：仮に失敗してもすぐにやめない

楽観性：生きているのでOKくらいの、失敗や不安ごとを重く捉えすぎない

冒険心：失敗を恐れずに始める

柔軟性：新しいものを受け入れ続ける。変化を歓迎する

このような行動特性を持った人が偶然を呼び込みやすいとされている。

この本には、偶然を受け入れて自身のキャリアにつなげた方の事例が多数紹介されている。本を読んだ限り、この5つの行動特性がそろってなくても偶然は引き起こせるようでした。

 

私の日々の活動と行動特性

サポートエンジニアに興味を持ちカジュアル面談をするも、選考に進めなかった。

選考に進めなかった原因は、求めるレベルに届いていなかったことと考えた。

幅広い知識を身に着けるため、基本情報技術者試験の勉強を合格した。

社内で技術的な話をすると「えっ、そんなことも知らないの？」と言われることがあり、試験に合格しただけでは、十分な知識が身についていないことを実感した。

また「サポートエンジニアに転職した方」のブログに「自分から情報発信できることを重視されているように感じた」と書かれていたのでさっそくブログを作成する。

beasupportengineer.hatenablog.com

サポートエンジニアに関して考えたことをまとめたり学んだ技術を説明する練習の場としてブログを活用できれば満足。もしかしたら採用担当の目に届くかもしれないと思い、1日のアクセス数が0でもかまわずブログを継続する。

4月半ばまでは応用情報技術者試験の勉強をし、その後はカジュアル面談で聞かれた技術について説明できるようにブログにまとめていきたい。

具体的には以下の4つをやる。

www.he.u-tokyo.ac.jp

行動特性に当てはめる

好奇心：業務で触れる機会がない技術に対しても学習する

持続性：サポートエンジニアの選考に進めなくても学習を継続した

楽観性：ブログやTwitterで発信し続けていれば採用担当の目にとまるかも！と考える

冒険心：1日のアクセス数が0の日があっても淡々とこのブログを更新する

柔軟性：やり方がよくないと思えば、やり方を変える

偶然の発生しやすさを計画的に高める

これまでの私の活動を振り返り、5つの行動特性に当てはめることができた。

私の存在を見つけてもらえるように発信する

この本を読んだとき、自分の存在を知っている人がそばにいて＆声をかけてもらって偶然をキャリアに活かしている人が多いような印象をうけました。

「私が転職したときはこんなスキルが評価されましたよ！」や「うちでは今こんな人材を探してまして…」といった情報を手に入れるためにも私の存在をアピールしつつ話しかけやすいオーラをまとわないとな・・・。

 

私はサポートエンジニアに興味を持っています！

サポートエンジニアを目指している人はここにいますよ！

お気軽に声をかけていいですよ。

私がどんな人物であるかイメージできるような内容を発信する

サポートエンジニアとして活躍している姿がイメージできなければ、たとえ自分の存在が知られていても声をかけてもらえない可能性があると思っています。

なので、読み手がイメージできるレベルで以下のことを説明できる状態にすることが有効ではないでしょうか。

  • 現職での私の強みと強みが活きたエピソード
  • サポートエンジニアに求める技術への理解度
  • サポートエンジニアに興味を持ったエピソード

この辺りをまとめて、私がイメージするサポートエンジニア像と御社で活躍中のサポートエンジニアとの差が把握できたらいいなぁ。

他に考えていること

「王道の正面突破が難しいので、他の人と違う方法をとったらうまくいった」みたいな話がありまして、偶然から始めるキャリアプランと似てるな(もしかして一緒？)と思いました。

このnoteを併せて読むと、さらにアイディアが浮かんできそう。

kensuu.com

おわりに

こんな感じで私は現在進行形で偶然を引き寄せようと楽しくジタバタしています。

正解がわかっていない問題に取り組むときほど頭をフル回転して何とかしようとする。

その過程が人間らしくて好きだし、サポートエンジニアのお仕事もこの状態に近い気がする。

 

ここまで、読んでいただきありがとうございます。

今後も私の行動や発信に注目してください！

お気軽に声をかけていいですからね。

開発エンジニアからテクニカルサポートエンジニアになった方のブログに共感したのです！

サポートエンジニア 私について

開発エンジニアからテクニカルサポートエンジニアになった方の話を見つけました。

blog.riywo.com

現在、私は開発エンジニアであり、次のキャリアとしてサポートエンジニアを目指しています。私とこの方との間に共通する考え方があるか気になったのでまとめます。

私は「ここ」に共感した！

念願かなって Software Engineer として働いてみましたが、先日人に言われて改めて気づいたのが、僕は Software Engineer になりたかった訳ではなくて、Software Engineer をしてみたかっただけなんですね。

はじめてこの記事を読んだとき、1番ここが刺さりました。まるで自分事のように。

知識豊富のSoftware Engineerからの質問が刺さったことを思い出す。

「自宅ではプログラミングで何か作ったりしないんですか？」という質問にハッとさせられた記憶があります。『私は、本当に開発したいのか？』と。

私に質問した方は「これを自分の手で作りたいんだ！」といったものがあり、帰宅後も開発をされているようなThe開発エンジニアです。どうしても開発がしたくて仕方がないような感じ。

一方、私は帰宅してからプログラミングすることはありませんし、そもそも作りたいものがない(イメージできない)。

私は「Software Engineer になりたかったわけではなくて、Software Engineer する能力を身につけたかった」んだろうなと思いました。

Software Engineer は自分が担当する system については文字通り上から下まで責任持って自由にやれます("You build it, you run it" でした)が、担当外のものについては結局手が出せないことが多いなと感じました。言い換えると、自分が手を出せる範囲が非常に狭く深いです。

良くも悪くもこれなんですよね。自分が担当したsystemに対して色々できるのですが、担当したものしか手を出せない(ことが多い)。これはこれで楽しいのですが、systemが完成するまで短くて数カ月、巨大なsystemになると数年かかったりします。また自分が触れる技術は、参加したプロジェクトの担当箇所でほぼ決まるため、数年間で振り返ると、私がやってきたことは偏ってて意外と少ないのでは？と思ったりします。

IT業界に入って基本情報の勉強したときに「ITって、こんなに範囲広いのかよ！」と驚いていたわりには身に着いた技術の範囲は狭いかも。と感じています。

色んな技術に触れてみたい思いはあるため、今はSoftware Engineerとしてやっていけても、いずれは熱が冷めて飽きてしまいそうです。

Software Engineer以外の道としてSupport Engineerを目指している

プログラミングを触ったときに、「これさえあれば、何でも作れるのか！すごい世界だ！！」と思ったから私はSoftware Engineerになったわけですが、エンジニアの仕事は多岐にわたることエンジニアになって知りました。

現在は、Software Engineer以外の道としてSupport Engineerを考えています。(このブログのタイトルでもありますし。)

理由は4点

  • 困っている方の力になるのがすき
  • バグの原因を特定、解消できたらうれしい
  • 困っている方の課題が解決できたら私もうれしい
  • ユーザーの課題に対してブレずに応えたい

Technical Support Engineer がいいなと思った理由は、お客さんの課題を直接的に知ることができて、それを service 改善に自分でつなげやすいと思ったからです。Software Engineer だと、どうしてもそうした今起こっている課題を間近で見る機会というのは減ってしまって、ともすれば今開発しているものが一体何のためのものだったのかブレてしまうこともありがちです。

この辺は、まったく同じことを思いました。(ユーザーとの距離と開発にかかる期間がそうさせるのでしょうか。)

ユーザーのぼんやりした課題をうまく言語化してプロジェクトを開始するも、走り出している間に作りたいものがブレていき、最終的には「思っていたのと何か違うもの」が完成する。Software Engineerをやっていてもどかしい瞬間です。

Support Engineerはユーザーとの距離が近く、プロジェクト1つのサイクルが(Software Engineerと比べて)短く、課題とあるべき姿が明確なため、ユーザーの課題解決に特化できる点がいいなと思ったのです。

これからの私

業務で扱う技術・自分が興味を持った技術に関して今もこれからも貪欲に学んでいきます！(明日、面接しませんか？と言われるかもしれないですし。)

最近は、業務外に学んだこと(やったこと)を記録するようにしています。

※もちろん日々の業務も全力で取り組んでいます。

チャンスをみすみす見逃さないように、今できることを積み重ねていきたい。

私はサポートエンジニアに興味を持っています。採用担当の方や現役エンジニアの皆さんからのお声がけ、いつでもお待ちしております！

応用情報技術者試験のシステム監査で高得点とるためのまとめ

サポートエンジニア

参考になりそうなサイト

masassiah.web.fc2.com

監査人に任命するにあたり確認する独立の観点(R2秋)

  • 監査人の所属部門が監査対象と同じ指揮命令系統に属していないこと
  • 以前に監査対象の領域または業務に従事していないこと

具体的に確認すべき項目として解答すべきことは

  • 担当から離れて一定期間経過していること
  • 開発・保守業務に対する関与度合い

など。

監査手続の考え方

「必要な手続」の見つけ方

  1. 本文を読んで、業務手続き(登録や承認であり監査手続きではない)の手順をまとめる。
  2. 必要な手続きを見つける
  3. 見つけた手続きに「記録」をつけるか検討する

監査の結論を裏付けるために十分で適切な監査証拠を手に入れることができるものである必要があります。

不要な権限の見つけ方

  1. 本文を読んで、業務手続き(登録や承認であり監査手続きではない)の手順をまとめる。
  2. 誰に何の権限がある・ない・不明をまとめる
  3. ない・不明の権限が仮に付与されていた場合、1のフローを通さずに業務手続きができてしまうものを選ぶ

その他(本文の単語+本文にない業務動作の単語)

承認権限はあるので、入力権限も付与されていたら不正が可能になる(R2秋)

監査実施の注意点

エラー処理などの監査をする際に、架空のデータを使うことがあります(テストデータ法)。

そのとき注意することは、実在するデータとして処理されないようにすることです。

例：監査人が作成した発注データが受注確定されてしまわないこと

改善が必要になること

担当者が入力と承認を行うことができること

移行作業表を作成するのは開発担当者で、移行するのは以降担当者だが、開発担当者も移行に関する権限が与えれらてしまっているため、場合によっては移行作業表を作成せず移行できてしまう(R1秋)

システムを介さない手続き(R1秋)

「システムの権限設定を見てシステム利用者の職務分離が確保されているか確認する」手続きでは、システムを介さずにデータを入力・修正したものを確認する手段がない

監査手続の技法

インタビュー法

監査対象の実態を確かめるため、システム監査人が直接、関係者に口頭で問合わせ回答を入手する技法

チェックリスト法

システム監査人が、あらかじめ監査対象に応じて作成されたチェックリストに対して関係者から回答を求める技法

突合・照合法

関連する複数の証拠資料間を突き合わせること、記録された最終結果について、原始資料までさかのぼってその起因となった事象と付き合わせる技法

ペネトレーションテスト

システム監査人が一般ユーザのアクセス権または無権限で、テスト対象システムへの侵入をためし、システム資源がそのようなアクセスから守られているかどうかを確認する技法

その他

職務の分離(R3春)

業務の担当者と承認者を分離し、職責と権限を適切に分配することで、各者間での相互牽制を働かせること

ビジネスを有利にはたらくための情報

取引先の見積額

応用情報技術者試験のDB問題で高得点とるためのまとめ

応用情報技術者試験 DB

エンティティの考え方

多重度

種類は以下の4つ。この中からどれを選ぶか考え方を考える。

ー：1対1

→：1対多

⇔：多対多

1対多(R2)

これを記述するパターンが1番多い。矢印の向きは主キーから外部キーへの向き。

A(主キー)　→　A(外部キー)

A(外部キー)　←　A(主キー)

⇔：多対多

第3正規形にしないといけないため、多対多を書くことはなさそう。

属性

リレーションシップの矢印の向きと隣り合う属性をみて、判断。

隣り合うエンティティの主キー・外部キーになっているものが、空欄に記述する属性になる。

主キー：テーブルの行を一意に識別する。

隣に主キーがあれば、記述する属性は外部キー。

データウェアハウスでの考え方(あくまでR3)

要件を満たすためのデータモデルを作成するため、分析に不足している属性を本文から抜き出す。

現状のER図のままだとエラーになることが判明した(R1)

主キーが同一のレコードを登録して実行時エラーになるパターンが多そうです。

対応策として、エラー原因となっている表の主キーをみなおし、主キーを別の属性に変更することです。

正規化

第1正規系

テーブル中に複数の値をもつようなデータ項目を含まないよう整理

第2正規系か判断する

「主キーAと主キーBが存在し、非キー属性Cが異なれば主キーAは異なる」

→非キー属性Cは主キーAに関係従属し、主キーBには関係従属しない

なので第2正規系になっていない

第2正規系でなくても問題がない理由

本文に、「テーブルの内容は変更されることはない」と記載されるパターンが多い。

回答例：〇〇テーブルに追加された行の値がその後、変更されることはない

※テーブルの内容(主キー)が変更になった場合、複数の行を同時に変更しないといけないため、更新漏れが発生しそう

第2正規系

第1正規系の表に対して、主キーの一部の項目だけに従属するような項目を含まないよう整理

候補キー

主キーの候補になりうる項目

代替キー

主キー以外の候補キー

非キー属性

候補キー以外の項目

第3正規系

第2正規系の表に対して、主キー以外の項目に従属するような項目を含まないよう整理

SQL文の考え方

どの表が使われているか確認すること！

困ったら本文を探そう。見逃している条件があるかも！

SQLの実行順序

FROM

JOIN

WHERE

GROUP BY

SUMやAVEなど

HAVING

SELECT, DISTINCT

ORDER BY

LIMIT

SELECT 列名(または＊) FROM テーブル名 WHERE 条件式

例：

SELECT COUNT(*) FROM 従業員

SELECT 単価 * 0.5 FROM 商品

細かい条件

SELECT DISTINCT 商品名 FROM 商品

重複を除く

SELECT 年齢, COALESCE(性別,2) FROM 会員

 NULL値を別の値に変換する

SELECT 日付, (CASE WHEN 時刻 < 12 THEN 0 ELSE 1 END) FROM 入館

SQL文で条件式を使う

JOIN句

INNER JOIN 結合するテーブル B ON A.属性 = B.属性

両方のテーブルにあるデータのみを取り出す(内部結合)
2つのテーブルにあって、合体できるデータのみを取り出します。

エンティティが1対1のときはこれを使用(R3)

LEFT JOIN 結合するテーブル B ON A.属性 = B.属性

左のテーブルをすべて表示して結合(外部結合)

RIGHT JOIN 結合するテーブル B ON A.属性 = B.属性

右のテーブルをすべて表示して結合(外部結合)

WHERE句による条件設定

WHERE 予約日 BETWEEN '20220306' AND '20220310'

範囲を指定する

WHERE 予約日 IN ('20220306', '20220310')

()内の値が対象

WHERE 名前 LIKE '_太郎%'

_は任意の1桁、%は任意の0～N桁の文字

WHERE 電話番号 IS NULL

NULLを抽出

WHERE 電話番号 NOT IS NULL

否定した条件

GROUP BY句(R3 SELECT文にCOUNTがあればGROUP BY)

SELECT 予約日, SUM(予約人数) FROM 予約明細 GROUP BY 予約日

SUM()以外にはAVG(),MAX(),MIN(),COUNT(*)などがある

GROUP BY句とHAVING句(R2)

SELECT 予約日, SUM(予約人数) FROM 予約明細 GROUP BY 予約日 HAVING COUNT(*) > 3

ORDER BY句

SELECT 予約番号, SUM(金額) FROM 予約明細 GROUP BY 予約番号 ORDER BY 予約番号 ASC

昇順はASC、降順はDESC

副問合せ

  1. 内側のSELECT文を実行
  2. 1で取得した値を用いて外側のSELECT文を実行

例：

SELECT 宿泊日, 利用料金 FROM 予約明細

 WHERE 顧客コード IN (SELECT 顧客コード FROM 予約 WHERE 担当ID = '100')

相関副問合せ(R2,H31)

EXISTSやNOT EXISTSを使った存在チェックで使用することが多い。

副問合せでは「該当データが存在するかどうか」という結果が分かればいいので、副問合せの列名は「*」を使用する。

  1. 主問合せを実行する(外側のSELECT文)
  2. 1で取得した値を用いて副問合せを実行する(内側のSELECT文)

例：

SELECT 施設ID, 部屋種別ID, COUNT(*) FROM 部屋

 WHERE NOT EXISTS (

  SELECT * FROM 予約明細 WHERE 予約明細.部屋ID = 部屋.部屋ID

    AND 予約明細.宿泊日 >= :チェックイン日付 AND 予約明細.宿泊日 < :チェックアウト日付)

 AND 施設ID = :施設ID AND 部屋種別ID = :部屋種別ID

 GROUP BY 施設ID, 部屋種別ID

 HAVING COUNT(*) >= :部屋数

INSERT

INSERT INTO 予約 (氏名, 日付, 担当者, コースコード) VALUES('山田山男', '2022-03-07', '佐藤佐子', '08')

試験問題では、VALUESの値が書かれているケースは少なそう。

INSERT INTO 予約 (コースコード) SELECT DISTINCT 予約 FROM コース

R1

UPDATE

UPDATA テーブル名 SET 列名 = 変更値, ・・・ WHERE 条件式

試験問題では、変更値がSELECT文になっているパターンが多い。

使用しているテーブル名を見て問題に答えること

DELETE

DELETE FROM テーブル名 WHERE 条件式

WITH(H31)

WITH 副問合せ名 AS (クエリ文)：副問合せ名

UNION(H31)

同じ列名が存在する2つのSELECT文をつなぐ

SELECT 列名A FROM テーブルB UNION SELECT 列名A FROM テーブルC 

重複は1つにまとめる

SELECT 列名A FROM テーブルB UNION ALL SELECT 列名A FROM テーブルC 

重複もそのまま表示する

制約

非ナル制約

ある列にNULLが入らないようにする制約

UNIQUE制約(R2)

指定した列・列の組み合わせが一意であることを強制する制約

主キー制約

指定した列・列の組み合わせに1つだけ主キーを指定

検査制約

指定した列の内容を指定した条件を満足するもののみにする制約

参照制約

参照元テーブルに外部キーを指定する

データウェアハウス設計のスキーマ(R3)

スタースキーマ

1つのファクトテーブルの周囲に、複数のディメンションテーブルが単一の階層で関連付けられる。

ファクトテーブル：分析対象のデータを格納したテーブル

ディメンションテーブル：ファクトテーブルの外部キーから参照する主キーを持つマスタ系テーブル

スノーフレークスキーマ

スタースキーマのディメンションテーブルを正規化(階層化)した構造

データマート(R3)

データウェアハウスに格納されたデータから特定の用途に必要なデータだけを取り出し、構築する小規模なデータベース。

データウェアハウスで分析するのに時間がかかりすぎる場合、データマートを追加する。

つまり「データマートの表を見れば分析できる」という状態がのぞましい。

3層スキーマ

データモデルより前のデータベースの構成（概念スキーマ、外部スキーマ、内部スキーマ）

DNSのセキュリティ対策などの考察

セキュリティ 応用情報技術者試験

DNSのセキュリティ対策について考えます。(参考：R3春 応用情報)

DNSサーバの種類

権威DNSサーバ(DNSコンテンツサーバ)

  • ドメインの名前解決の情報を持っている
  • 外部からの問合せに対して、自身が保持する情報を応答する。

キャッシュDNSサーバ

  • ドメインの名前解決の情報をもたない
  • 外部に問い合わせを行って、その結果をクライアントに返す。
  • 結果はキャッシュとして一定期間保持する

DNSの名前解決の種類(H30午前)

再帰的な問合せ

リゾルバから名前解決要求をうけたDNSサーバが他のDNSサーバに代理して問い合わせを行い、最終的な結果をリゾルバに返す必要のある問い合わせのこと。

反復問合せ

リゾルバから再帰的問合せを受けたDNSサーバがそれを解決できるまで繰り返し他のDNSサーバに行う問い合わせのこと

SSL証明書とDV・OV・EV

DNSサーバのインシデントの再発防止としてSSL証明書の話があげられていたのでまとめます。

参考：SSL証明書とは？仕組みや種類についてわかりやすく解説 | システム運用ならアールワークスへ

SSLとは

インターネット上の通信を暗号化する仕組みです。

SSL証明書とは

公正な第三者機関である認証局(CA)が、通信先のサーバが実在することを証明し、通信相手に偽りがないことを証明する

SSL証明書に含まれる鍵(公開鍵・秘密鍵)を用いて、ブラウザとサーバ間でやりとりされる通信を暗号化する

ドメイン認証(DV)

ドメイン名の所有者であることが確認できる

企業実在認証・組織認証(OV)

登録簿などを確認し、組織として法的に実在していることが確認できる

EV認証(EV)

上記2つの認証に加え、物理的に組織が存在するか、事業が存在・運営されているか、承認者・署名者が確認できる

DNSキャッシュポイズニング

DNSキャッシュサーバに偽のDNS情報をキャッシュとして登録させ、ユーザに偽サイトへ誘導する攻撃。

DNSキャッシュサーバに偽のキャッシュ情報を登録させる手順

  1. 攻撃者はキャッシュサーバに対して偽の再帰的な問い合わせを行い、反復問合せを強制的に生じさせる
  2. キャッシュサーバはコンテンツサーバに対して反復問合せをする
  3. 攻撃者はコンテンツサーバが正規の応答をするよりもさきにキャッシュサーバへ偽の応答を送りつける
  4. キャッシュサーバは攻撃者から送り付けられた偽の応答を正規のものと判断し、キャッシュに登録する。

対策

再帰的な問い合わせに対して内部ネットワークからのものに限定する。

DNSSEC

DNSの正当性を保証するための拡張仕様。

公開鍵暗号方式のディジタル署名を用いて、正当なDNSサーバからの応答であることをクライアントが検証する

 

 

情報セキュリティ10大脅威2022個人編の考察

セキュリティ

情報セキュリティ10大脅威2022個人編が出た

https://www.ipa.go.jp/files/000096258.pdf

 

情報セキュリティ10大脅威2022

2021年において社会的に影響が大きかったセキュリティ上の脅威について「10大脅威選考会」の投票結果に基づき順位付けがされています。

個人向けと組織向けの脅威は以下のようになっていました。

個人向けの脅威

  1. フィッシングによる個人情報等の詐欺
  2. ネット上の誹謗・中小・デマ
  3. メールやSMS等を使った脅迫・詐欺の手口による金銭要求
  4. クレジットカード情報の不正利用
  5. スマホ決済の不正利用
  6. 偽警告によるインターネット詐欺
  7. 不正アプリによるスマートフォン利用者への被害
  8. インターネット上のサービスからの個人情報窃取
  9. インターネットバンキングの不正利用
  10. インターネット上のサービスへの不正ログイン

組織向け脅威

  1. ランサムウェアによる被害
  2. 標的型攻撃による機密情報の窃取
  3. サプライチェーンの弱点を悪用した攻撃
  4. テレワーク等のニューノーマルな働き方を狙った攻撃
  5. 内部不正による情報漏洩
  6. 脆弱性対策情報の公開に伴う悪用増加
  7. 修正プログラムの公開前を狙う攻撃(ゼロデイ攻撃)
  8. ビジネスメール詐欺による金銭被害
  9. 予期せぬIT基盤の障害に伴う業務停止
  10. 不注意による情報漏洩等の被害

SNS上で話題になった(少なくとも自分が目にした)脅威

「2021年　脅威の名称」で検索すると話題になったニュースが見つかります。

ワクチン接種の予約システム脆弱性とゼロデイ攻撃

ワクチン接種の予約システムが架空の予約番号で予約できる脆弱性が判明し、対策がされる前にSNSやマスコミでそのことが拡散されてしまった。

その結果、興味本位で予約する人も現れ、本物と偽物の予約の区別がつかなくなった。といったところでしょうか？

ゼロデイ攻撃をするのはもちろんNGですが、ゼロデイ攻撃につながるような情報発信も危険だと思ったことを覚えています。

部品工場がランサムウェアの攻撃を受け、トヨタが国内全工場停止

これは2022年3月1日の出来事ですが、組織向けの脅威1位のランサムウェアの内容だったため取り上げます。

「日本のトップ企業のトヨタの工場停止に成功した。それなら日本の他の企業にランサムウェアの攻撃しても有効だろう」みたいな考えになっている気がするので、今後もランサムウェアの被害が増えていきそう。

ランサムウェアとは
  • Ransom(身代金)とSoftware(ソフトウェア)を組み合わせて作られた造語
  • ランサムウェアはマルウェアの一種(悪意のあるソフトウェア)
  • 端末を利用できないように暗号化し、身代金を要求する(身代金を払っても復号してくれない気がする)

とはいえ、ランサムウェアで攻撃すると企業に反撃される時代になったようです。(日本にも、このような企業があると心強いのですが)

gigazine.net

情報セキュリティ対策の基本

ソフトウェアの脆弱性

ソフトウェアの更新：脆弱性を解消し攻撃によるリスクを低減する

ウイルス感染

セキュリティソフトの利用：攻撃をブロックする

パスワード窃取

パスワードの管理の・認証の強化：パスワード窃取によるリスクを低減する

設定不備

設定の見直し：誤った設定を攻撃に利用されないようにする

誘導(罠にはめる)

脅威・手口を知る：手口から重要視するべき対策を理解する