Rundevlog

小さい会社のしがないエンジニアのブログ

【書籍紹介】オブジェクト指向でなぜつくるのか

今回は書籍紹介をさせていただきます。

今回紹介する本は、平澤章著『オブジェクト思考でなぜつくるのか(日経BP社)』です。

僕は、オブジェクト指向で書く理由がイマイチ分かりませんでした。

何となく、オブジェクト指向言語とか言われている言語を使用しているが、そもそもクラスの使い方とかフレームワークやライブラリを使用する時以外使わないでしょみたいな感覚でした。

そういう方におすすめの方一冊がこちらの一冊になります。

この本で学習できること

この本では下記の3点について学ぶことができます。

・そもそもオブジェクト指向とはなにか

・プログラム言語の進化とオブジェクト指向言語の必要性

・プログラムによるメモリの使用量を解説しながら、オブジェクト指向で書くことによるメリット

・上流工程への応用

ぱっと見難しそうなタイトルや初版年が2004年で少し難しそうとか、情報が古いのではないかと思う方も多いかと思います。

でも、実際には、分かりやすくオブジェクト指向について解説しており、初版から20年近く経った現在も使うことができるプログラミングやコンピュータサイエンスの知識ではないかと思います。

僕は、独学でプログラミングを学習し、情報処理技術者試験などの資格勉強をしましたが、どうしても開発に関して抽象的すぎる概念を捉えるだけ、試験のための丸暗記をするだけに留まってしまいました。

PHPやJavaScriptではProgateで出てきたところだけを何となく理解し、あまり使い方が分からないため、実践することもなく敬遠していましたし、

また、メモリについても基本情報技術者試験の勉強である程度勉強していましたが、イマイチそれ自体がプログラミングと結び付かず、プログラムを書く際に意識することもありませんでした。

新しい知識と今まで学習してきたことが結びつく一冊となっていると思いますので、プログラミング学習で初学者レベルの習得にひと段落ついた方には是非一度手に取ってもらえたらと思います。

DKIMについて解説

こんにちはかじです。

今回はDKIMについて解説したいと思います。

メールに〇〇経由と表示される理由

たまに受信したメールの宛先に「〇〇を経由」という記載があったりします。

(〇〇にはamazon-sesなどのサービス名が入ります)

これは、Amazon SESなどのメール送信用のサービスを使用してメールを送信していることを表していますが、なぜそんなことをわざわざ記載するのでしょうか。

これは、差出人のメールアドレスのなりすまし防止です。メール送信用のサービスを使用すると差出人のメールアドレスがどんなアドレスであろうとメールを送信することができてしまいます。つまり、実際に差出人のメールアドレスの持ち主でなくても差出人を偽ってメールを送信できてしまうのです。そうならないためにメール送信のためにサードパーティから送信された場合、メールクライアントによっては、サードパーティを経由している事を明示することで、なりすましの可能性をユーザーに伝えているのです。

なりすましを防止するために -DKIMとは-

なりすまし防止はありがたいのですが、メール配信を行っている人からすると、ちゃんとそのメールアドレスを保持しているのに、いちいち疑われたら、いい迷惑ですし、受信した側からしても、正しいドメインから送られているのにメールを信頼できないというのは、面倒な話です。

そこで登場するのがDKIMです。

DKIMは、DomainKeys Identified Mailの略で電子メールの認証を行う仕組みです。

このDKIMを設定を行う事で、サードパーティを使用していたとしても、メールアドレスのドメインを認証してくれることによってなりすましではないことを証明してくれます。

DKIMの仕組み

ではどうやってなりすましでないことを証明するのでしょうか。

まず、公開鍵と秘密鍵を用意し、メール配信用のサードパーティに秘密鍵、メールアドレスのドメインのネームサーバーには公開鍵を配置します。

メール配信の際にメールに秘密鍵を添付してメールを送信します。メール受信用のサーバーはメールを受信すると、その秘密鍵を持ってドメインのネームサーバーに問い合わせを行い、公開鍵と秘密鍵の照合を行い、差出人のドメインを保証されたメールであることを確認します。

まとめ

営業メールなどで認証されていない事を目にすることもあります。営業メールなど訝しげに見られがちだったりするので、それによって中身を見られないということもありますし、場合によっては迷惑メールに含まれてしまう可能性もあるので、是非KDIMは、設定しておくと良いでしょう。

Let’s encryptとは -無料でSSLを設定する-

こんにちは、かじです。

今回はLet’s encryptについて解説します。

Let’s encrypt とは

Let’s encrypt とは非営利団体のInternet Security Research Groupにより運営されている証明書認証局になります。Let’s encryptを利用することで無料でSSL証明書を発行することができます。

レンタルサーバーを使用していて無料でSSL設定をしてくれる場合、多くはこのLet’s encryptを使用しています。

ACME(Automated Certificate Management Environment)プロトコルと呼ばれるSSL証明書を自動発行する仕組みを利用しているため、証明書の発行を依頼して数分でSSLの設定が完了し、利用することができます。

Let’s encryptでできること/できないこと

無料の証明書サービスだから性能が心配という方もいらっしゃるかと思います。

もちろん無料サービスですので出来ないこともありますが、他方用途によっては性能を気にすることなく使用することも可能です。

次はその点について解説したいと思います。

Let’s encryptでできること

まず、Let’s encryptはDV(ドメイン認証)型のSSL証明書です。そのため、ドメインの所有者の正当性を証明してくれます。また通信内容の暗号化についても有料のSSL証明書と変わらず、行うことができます。

Let’s encryptでできないこと

繰り返しになりますが、Let’s encryptはDVであるため、ドメインの所有者の正当性を証明できても、所有者の組織の実在や活動状況などについては証明できません。

そのため、ECサイトなどの商用利用を目的をしている場合やには、有料であってもOV型やEV型のSSL証明書の発行サービスを利用することをおすすめします。

Let’s encrypt を使用する際の注意点

Let’s encryptでは有効期限が90日となっています。1,2年が有効期限のSSL証明書が多数ですが、それに比べて有効期限が短いというところが注意点です。それについても自動更新を設定しておくことで有効期限の漏れがなくなることはないでしょう。

まとめ

いかがでしたでしょうか。ポートフォリオの作成などでアプリケーションやWEBページを公開する際に、やはりSSLは気にしたいところですが、お金をかけるのもなあということもあるかと思います。そういう場面では是非Let’s encryptを使用したら良いのではないかと思います。

今回はここまでになります。最後まで閲覧くださり、ありがとうございました。

URL直打ちアクセスに対応しようか【AWS WAF】

今回はAWS WAFでIPアドレス直打ちによるアクセスを防ぐ方法を紹介します。

IP直打ちアクセスによるデメリット

IP直打ちによってアクセスされることのデメリット、反対にIP直打ちによってアクセスをブロックすることのメリットは何でしょうか。主に信頼性の観点から挙げられます。

1つ目はドメインだけのアクセスに絞ることで、知らず知らずのうちにIPでアクセスした際に、不信感を持たずにサイトを使用することができるということ。IPアドレスでアクセスすることを防ぎ、周知させることで、IPアドレスでサイトを展開しているようなフィッシング対策にもなります。

2つ目はSSLを強制することができるということです。IPアドレスを直打ちによるアクセスは、HTTPSで有効な通信を確立することができません。盗聴リスクおよびログイン情報の盗聴による不正アクセスの危険性を踏まえると、HTTPS以外の通信をブロックする、ないしはHTTPSへリダイレクトさせることが好ましいと言えます。

この2点からIPアドレス直打ちでは、リダイレクトするからアクセスできないようにするかという対応が必要になると考えます。

IP直アクセスによるブロックの手順

どうやって対応するのか

HTTPリクエストヘッダーの中のheader(http 2だと:authority)に、リクエストを送った際に使用したIPやドメイン情報などが記載されています。そちらを見てIPアドレスでアクセスしていたらブロックするという方法で良いかと思います。

手順0.前提条件・事前準備

WAFを作成する前に、WAFをアタッチする予定のリソースを作成する必要があります。今回はALBをあらかじめ作成しております。

手順1.ALBのIPアドレスを確認

EC2のコンソール画面から「ネットワークインターフェース」からALBのIPアドレスを確認しておきます。

手順2.IP setsの作成

まず、IPのグループであるIP setを作成します。

AWS WAF & Shieldsのコンソール画面からIP setsの画面を開きます。

リージョンを東京リージョンに変更し、「Create IP sets」をクリックします。

適当なIP sets名を作成し、IP versionでIP v4を選択し、IPアドレスを入力します。注意としてはCIDR表記をしなければいけないという点です。今回は/32としておきます。

また、ALBは複数のIPアドレスを保持しているので、両方のIPアドレスを追加したいという場合は、改行して追加してください。

手順3.Web ACLを作成する

続いてWeb ACLの作成です。

AWS WAF & Shieldsのコンソール画面からWeb ACLの画面を開き、東京リージョンを選択し、「Create Web ACL」をクリックします。(キャプチャし忘れたので、画像はありません)

続いて、Web ACL DetailsでACL名などを入力します。(こちらもキャプチャし忘れたので、画像はありません)

Associated AWS resourcesで作成しておいたALBを追加します。

「Add AWS resources」をクリックします。

「Appliccation Load Balancer」をクリックし、作成したALBを選択し、「Add」をクリックします。

WAFにアタッチするリソースにALBにリソースが追加出来たら「Next」をクリックします。

続いて「Rules」でWAFのルールを作成、追加していきます。

「Add rules」→「Add my own rules and rule groups」をクリックします。

「Rule type」では「IP set」を選択し、適当にルール名を入力します。

「IP set」で先ほど作成したIP setを選択します。

「IP address to use as the originating address」ではリクエストのソースIPを検査対象とするのか、ヘッダー内に記載されているIPを検査対象とするのかを選択します。今回はヘッダー内を検査したいので、「IP address in header」を選択します。

「Header Field name」ではヘッダー内のどの項目を検査するかになります。今回はHost内を検査したいので、「Host」と記載します。

「Position inside header」は項目内のどのIPアドレスを見るのかになります。host内にIPアドレスが複数ある場合があるのかは分かりませんが、漏れがあると嫌なので「Any IP address」を選択します。

「Fallback for missing IP address」は無効なIPアドレスが含まれていた場合、IP setのアドレスに一致したアドレスとして扱うのか、一致していないアドレスとして扱うのかになります。どちらでもいいですが、ここでは「Match」としておきます。

最後に「Action」ですが、IPアドレスが一致していた場合どうするかになります。今回はアクセスをブロックしたいので「Block」を選択します。

ここまで出来たら、「Add rule」をクリックします。

元の画面に戻りましたら、設定内容を確認します。

ここでは「Default web ACL action for requests that don’t match any rules」を「Allow」に変更します。WAFルールに引っかからなかった場合、リクエストを許可するのか拒否するのかの項目になります。基本的なリクエストは許可していいので「Allow」を選択します。

次に「Next」をクリックします。

次の画面では、WAFルールの優先順位を決めますが、特に設定することもないので「Next」をクリックします。

メトリックスに関しての設定を行いますが、ここでは変更する点は特にないので説明を割愛します。

選択内容はそのままで「Next」をクリックします。

次の画面では諸々の設定を確認します。問題がなければ、「Create Web ACL」をクリックします。

動作検証とまとめ

これでIPアドレスでアクセスしてみるとちゃんと「403 Forbidden」でちゃんとアクセスがブロックされています。

これで一応IPアドレスによってブロックをできました。

カスタムルールだとWCUは5と低いので他のルールへの影響もそこまで大きくないので、防ぎたい攻撃がはっきりしている場合は、カスタムルールでセキュリティ対策をしてもいいのかなと思います。

ただ、今回の場合、ALBはAWSの内部メンテナンスによってIPアドレスが変わるので本当に意味があるのだろうかということが気になりました。そこらへんは次回に書いていきたいともいます。

LightsailでCloudWatch Logsに保管する

こんにちは。かじです。

今回はCloudWatch LogsでLightsailのログを収集する方法について解説します。

CloudWatchLogsではEC2やオンプレミスのサーバのログを収集し保管することができる機能です。EC2やオンプレミスのサーバが基本的な用途ですが、LightsailでもCloudWatch Logsでログを収集、保管することはできます。ログを収集する際にはインターネットを介してログをCloudWatchに送るだけですし、内部で動いているOSはLinuxですので、なんら問題はありません。

とりあえずやってみましょう。

1.IAMユーザーを作成する

LightsailもEC2オンプレミスと変わらないから問題ないはと言ったものの、いきなり問題発生です。LightasailにはIAMロールをアタッチできません。

解決方法は、IAMユーザーを使用することです。とりあえず、これ用のIAMユーザーを作成し、アクセスキーとシークレットキーを控えてください。

2.Lightsail側の設定

aws configureでプロファイルを作成

LightsailインスタンスにSSHで接続し、下記コマンドでaws configureプロファイルを作成します。

$ sudo aws configure --profile AmazonCloudWatchAgent

プロファイル名は適当で、作成したIAMユーザーのアクセスキー・シークレットキーを入力し、リージョンは ap-northeast-1 を入力します。

CloudWatchAgentをインストール

引き続き、SSH接続したまま、下記コマンドでCloudWatchAgentをインストールします。

$ sudo yum install amazon-cloudwatch-agent

と思ったのですが、yum:Command not foundとなってしまいyumが使用できないようです。ひとまず下記コマンドでOSを調べてみます。

$ cat /etc/issue

どうやらOSがDebian GNU/Linux 11だったため、yumではなく、aptでパッケージ管理されているとのことでした。

下記サイトにOSごとのエージェントのインストールファイルのリンクがあり、それをwgetコマンドでダウンロードし、dpkgで解凍します。

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-commandline-fleet.html

.debファイルのダウンロードコマンド

wget https://amazoncloudwatch-agent.s3.amazonaws.com/debian/amd64/latest/amazon-cloudwatch-agent.deb

ダウンロードファイルの解凍コマンド

sudo dpkg -i -E ./amazon-cloudwatch-agent.deb

CloudWatchエージェントの設定

引き続きSSH接続したまま、下記コマンドでCloudWatchAgentの設定を行います。
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

このコマンドでプロンプト形式で、CloudWatchエージェントの設定が始まるのですが、Lightsailの場合、下記の項目でデフォルトの回答を選択できません。

Are you using EC2 or On-Premises hosts?
Do you want to turn on StatsD daemon?
Do you want to monitor metrics from CollectD?
Do you want to monitor cpu metrics per core? Additional CloudWatch charges may apply.
Do you want to add ec2 dimensions (ImageId, InstanceId, InstanceType, AutoScalingGroupName) into all of your metrics if the info is available?
Do you want to monitor any log files?
Do you want to store the config in the SSM parameter store?

こちらの設定が完了すると下記パスにconfig.jsonファイルが作成されています。

CloudWatchエージェントの起動

下記コマンドでCloudWatchエージェントを起動します。

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m onPremise -s -c /opt/aws/amazon-cloudwatch-agent/config.json

psコマンドでCloudWatchエージェントが動いているのを確認します。

また、これでCloudWatchにアクセスしてログが収集できてることを確認できれば完了です。

⚫︎参考サイト

https://repost.aws/ja/knowledge-center/lightsail-monitor-with-cloudwatch

今日から君もVimmer-Vimで最低限覚えておきたいコマンド-

Linuxを使っているとVimを使わざるを得ない時が多々あります。

そんな時に最低限これさえ覚えておけば大丈夫というコマンドを列挙していきます。僕は普段これで乗り切ってます。

玄人になりたい人というよりは、なぜか分からないけどVimを使わないといけないという人向けになります。

Vimでファイルを開く

vi [ファイル名]

ファイルを編集する

aキーを押下するとファイル編集ができます。

ファイルの編集を終わる

編集状態でescキーを押下するとファイルの編集が終わります。

ファイルの変更を保存して終わる

ファイル編集が終わった状態で、下記コマンドを実行します。

:wq 

ファイルの変更を破棄する

ファイル編集が終わった状態で、下記コマンドを実行します。

:q!

特定の文字列の検索

/[文字列]

次の検索結果へ

n

Vimの難しい機能や仕様は把握してませんが、ひとまずこれで何とかVimを使用した作業ができます。