コスパ最強！Google Pixel 4aを最速で購入して使ってみた
2020年8月20日、Google Pixelシリーズの最新作Google Pixel 4aを購入しました！
Google Pixel 4aは昨年発売されたGoogle Pixel 4の廉価版モデルなのですが、前作のGoogle Pixel 3aも十分スペックが高く、発表前から高コスパスマホとして注目されていました。
私自身、4年ほど前SIMフリーに移行してからは、中古の端末(Xperia XZ、Xperia XZ1)を使っていたのですが、やはり型落ちした製品だということもあり、あまり満足はしていませんでした。
ただ、今回、発売されたGoogle Pixel 4aが税込み42,900円であることに驚き、それまで狙っていた、美品中古で42,800円のXperia 1(2019年6月販売)はあきらめ、購入を決断しました。
Xperia 1の参考情報は以下です。
今回は購入を決断した理由と、買ってみた感想をご紹介します。
ちなみに、私はGoogleの回し者ではなく、むしろSonyファンなので、その辺は安心して読んでいただければと思います(笑)
目次
購入前の期待値
今回、Google Pixel 4aを予約してまで購入したのには、いくつかの理由があります。
最近のスマートフォンは10万円近くするものも多く、普段は販売後のレビューを見つつ、購入を検討しますが、これからご紹介する3つの情報を事前に知っていたので、即決で予約購入しました。
値段はiPhone11の半額以下！
まず値段。 以下の表を見ていただくと分かる通り、とにかく安い！
| 機種 | 値段 |
|---|---|
| iPhone11(128GB) | 87,780円(税込) 79,800円(税抜) |
| iPhoneSE(128GB) | 54,780円(税込) 49,800円(税抜) |
| Google Pixel 4(128GB) | 10万3,950円(税込) |
| Google Pixel 4a(128GB) | 42,900円(税込) |
| XPERIA 5(128GB) | 75,900円(税込) |
| Xperia 8(64GB) | 33,310円(税込) |
Xperia 5の廉価版であるXperia 8も安いですが、ネット上の評判はあまりよくなく、それこそ、Google Pixel 3aのように、「安いけど高性能！」みたいな評判はあまりない印象です。
じゃあ、Google Pixel 4aはどうなの？というところですが、まずはカメラの性能について、ご紹介します。
ポートレートと夜景が最強のカメラ性能
筆者が、参考にした記事をまずはご紹介します。
以下の記事では、iPhone、Google Pixel、HUAWEI、Galaxy、AQUOS、Xperiaのシリーズすべてを比較したカメラランクを紹介しているのですが、その中でも、Google Pixelシリーズが、前作のGoogle Pixel 3a含め2製品ランクインしています。
また、スマホのカメラ性能を格付けしているDXOMARKという評価サイトでも、Google Pixelシリーズは100点以上の高いスコアを獲得しています。
https://www.dxomark.com/category/smartphone-reviews/
そして、Google Pixel 4aの評価について。
せっかくなので紹介したいところですが、別のスマホで撮影したものがなく、比較対象がないので、別の比較記事を紹介します。
iPhone 11 Pro Maxとの比較記事はこちら。
そして、Xperia 10IIとの比較記事はこちら。
これらからもわかる通り、他社のハイエンドモデルとも遜色ない性能ですね。
特に、ポートレート撮影と夜景撮影はとても高評価だと分かります。
モバイルPASMOの対応機種
意外と触れられないのが、モバイルPASMOへの対応です。
さすがに紙の定期券を使っている人はほとんどいないと思いますが、ほとんどの方は、ICカードの定期券か、モバイルSuica、モバイルPASMOを利用していると思います。
ただ、モバイルSuicaこそ普及していると感じますが、モバイルPASMOは如何せん、対応機種がめちゃくちゃ少ないです。
JRユーザならいいかもしれませんが、私のように、東京メトロや京王線、小田急線、都営地下鉄をはじめとした、私鉄を利用している人も多いはず。
となると、一つ荷物が増えてしまう理由にもなる、モバイルPASMOへの対応有無は非常に重要だと感じています。
そして、対応しているだけだと、不十分で、モバイルSuicaとモバイルPASMOが共存できないとモバイルSuicaを消さなくてはなりません。
こうなると、出張等でSuicaを使うサラリーマンにとっては致命的ですよね。
そんな中、Google Pixel 4aはモバイルPASMOとモバイルSuicaの両方使いに対応している希少なスマホだといえると思います。
購入してみて
前評判だけでも結構語りましたが、実際に届いた製品を手に取ってみて、感想も交えつつ、ご紹介しようと思います。
やっぱり、新品が家に届くと、めちゃくちゃテンション上がりますよね！
久しぶりにわくわくしながら、開封しました。
早速カメラを使ってみたのでご紹介しますが、めちゃくちゃきれいだと感じています！
カメラ以外に、購入後の感想をいくつかご紹介します。
- 画面が大きくてキレイ
- 先ほどご紹介したレビュー記事にもありましたが、画面が大きいです
- そして有機ELディスプレイのキレイさに改めて感動します
- 動きがサクサク
- 余計なアプリが入っていない
- セキュリティアップデートの早期適用
- データ移行が簡単
- SIMカードの取り出しに驚き
Google Pixel 4aとは関係ないけど。。。
Google Pixel 4aとは直接関係ないのですが、データ移行の際に、煩わしく感じた点について、言及します。
電子マネー移行が面倒
スマホのデータ移行で最も厄介なのが「モバイルSuica」です。
モバイルSuicaではSIMカードを挿した状態で引き継ぎ設定を行って、SIMカードを差し替えてから引き継ぎを実施します。
さらに、以前スマホが動かなくなって、移行した時に体験したことですが、モバイルSuicaは、上記の引き継ぎ手順を行えない場合、手数料を取って、引き継ぎを行います。
一方で、nanacoもWAONも同様のICカード機能ですが、SIMカードを差し替えずとも引き継ぎができますし、仮にスマホが動かなくても、電話一本で無料引き継ぎをしてくれます。
社会インフラに使われる通貨という特性も関係あるのかもしれないですが、そこもお金取るのか。。。と思ってしまいます。
ちなみに、QRコード決済は、IDとパスワード、さらにSMS認証で引き継ぎが可能なので、もっと簡単です。
自分の周りでもQRコード決済の利用者はまだまだ少ない印象ですが、こういったメリットもあるんですよね。
LINE移行のめんどくささ
そしてもう一つが、LINE以降のめんどくささです。
電話番号認証があったり、アカウントに複数のスマホからログインできなかったり。
当たり前に感じている人も多いと思いますが、SlackやFacebookと比べると、段違いにめんどくさいです。
それでもなりすましは起きるわけだし。。。
ちなみに、前はFacebookアカウントからLINEアカウントの作成ができましたが、今は電話番号と紐づけないとアカウントが作れないです。
そして、トーク履歴をしっかりバックアップしないと消える！
これまでのやり取りが消えてしまうと、やり取りの相手にもう一度連絡したりしないといけないですからね。
SlackやFacebookを使う機会が多いからこそ、こういう感覚なのかもしれませんが、トークのバックアップはLINEのインフラ上で保持して、アカウントに紐づけられて欲しいですよね。
あと今回、初めて気づいたのですが、トーク履歴の自動バックアップは設定できるようで、便利だなと感じたので、以下に紹介しておきます。
というか、良く調べてみたら、この機能2020年6月に実装されたばかりでした。
まじか。。。
スマホケースとフィルムのご紹介
今回、Amazonでスマホケースとフィルムを買ったのですが、いずれも売り切れになってしまっています。
根拠も併せてご紹介するので、再販売されたらご購入を検討してみてください。
- フィルム
- OVER'sという日本のメーカーの製品
- 値段も高すぎず、貼り付け用キットや問い合わせサービスもあって日本品質という感じ
- 3D全面保護ということもあり、うまく貼らないとケースと干渉するかも
- 筆者は何度かやり直したら干渉しなくなりました
購入したのは、ブルーライトカット版のフィルムなんですが、現在品切れになっていました。
ブルーライトカットではありませんが、同じメーカーの別の製品も販売されているのでご検討ください。
まとめ
今回は、スマホ購入のレビュー記事を書いてみました。
使い始めてからちょうど1週間くらいになりますが、特に不満もなく使えています。
仮に不満があったとしても、新品で4万2,800円だと考えると、許せてしまいそうな気がします。
最近はiPhoneやXperiaの廉価版も販売されていますが、特にカメラに関しては、Googleが強いのかなと思っています。
あとは、HUAWEIやGalaxy、XiaomiやOppoも気になりますが、PASMOの件を取り上げたことや、あとはキャリアとの親和性を考えると、日本で使うのにあまり優しくないような気がします。
しばらくは海外旅行にも行けないですし、おうち時間の充実のためにも、Google Pixel 4aの購入をご検討されてはいかがでしょうか。
Dharmaランサムウェアを利用し、日本を含む国々を標的にしたイランのハッカーグループの活動について
シンガポールを拠点に活動する、ロシアのセキュリティベンダGroup-IBのブログにて、イランのハッカーグループに関する活動観測が公開されました。
https://www.group-ib.com/media/iran-cybercriminals/
本記事では、その概要と関連情報について、まとめます。
目次
攻撃者の目的
Group-IBは2020年の6月ごろ、イランのハッカーグループによる攻撃を観測し、それらの攻撃が金銭目的であることを確認しました。
ただ、攻撃の痕跡や利用したツールを見る限り、国家の介入が推定されるイランの他のAPTグループとは異なり、初歩的なレベルの集団であると、Group-IBは結論づけています。
なお、攻撃の痕跡として、ペルシャ語を話すことや地理情報の痕跡も確認できているとのことです。
侵入に成功し、最終的にはDharmaランサムウェアを用いて、1~5BTCの身代金を要求するとのことです。
ちなみに、2020年8月25日現在、1BTCは約12万4300円で取引されています。
標的となった国
今回標的となった国々は以下です。
- ロシア
- 日本
- 中国
- インド
これらが標的になったと確認される根拠として、攻撃者のスキャン活動が、上記国々の属するホストの範囲に行われたことを挙げています。
そして、これらのホストが、「グローバルにRDPのポートを公開していないか」、「資格情報が脆弱でないか」という観点でスキャンが行われたことが推測されます。
なお、用いられたソフトウェアはMasscanというTCPポートスキャナーであることも判明しています。
Masscanの参考として、IIJの記事を掲載しておきます。
そしてこの手法は、昨年、TrendMicro、McAfee、Symantec等への不正アクセスを成功させたハッカーグループFxmspの用いる手法と類似していると、Group-IBは述べています。
ハッカーグループFxmspについても、参考記事を掲載します。
攻撃の手法
ホストへのスキャン活動により、脆弱なホストを特定した攻撃者はNLBruteというツールを用いて、ブルートフォース攻撃を行い、他のアクセス可能なホストから有効な認証情報を取得します。
RDPを悪用する際、NLBruteがよく使われているという内容は、2017年末のSophosの記事でも紹介されていました。
一部の攻撃では、CVE-2017-0213の悪用による権限昇格への試みも見られたとのことです。
他には、横展開の際に、ウィルス対策ソフト無効化のために「Defender Control」、「Your Uninstaller」を用いていたことが確認されています。
そして、Your Installerをダウンロードする際に、Chromeでペルシャ語を用いた検索クエリを使ったことも確認されています。
それだけではなく、攻撃者がペルシャ語のTelegramチャンネルからその他のツールをダウンロードしていたことも確認されています。
また、公開ツールであるAdvanced Port Scannerをもちいて、侵入後のスキャン活動を行いRDPにて、次の端末に侵入。
最終的に、Dharmaランサムウェアをダウンロードしたのち、手動で実行していたとのことでした。
Dharmaランサムウェアとは
今回の攻撃において、攻撃者はDharmaランサムウェアと他の公開されているツールを組み合わせることで攻撃を実現しました。
Dharmaランサムウェアは、Crysisという名でも知られており、今回のような脆弱な資格情報を持ったRDPを悪用した攻撃でよく用いられます。
あまり、詳しい日本語の記事がないのが残念ですが、JPCERT/CCの「ランサムウエアの脅威動向および被害実態調査報告書 1.0版」では、Crysisとしての解説が記載されているので、参考にしていただけるとよいかと思います。
この調査でも、「日本を含む世界各地での活発な感染活動」と述べられていますね。
https://www.jpcert.or.jp/research/Ransom-survey.pdf
なお、英語版の記事だと、Malwarebytesの記事が参考になるかと思います。
2019年5月当初でも、検出の増加傾向が確認できますね。
まとめ
Group-IBの執筆者はイランの攻撃グループについての新たな傾向として、以下のように述べています。
Dharmaのソースコードが広く利用可能になったことで、それを展開するオペレーターの数も増加しました。 イランは伝統的に国家の後援を受けつつ、潜入活動や破壊活動を行っていたので、単に金銭目的でのためにDharmaを使用し、スクリプトキディ(興味本位で被害を与えるクラッカー)の手に落ちたのは驚くべきことです。
イランのハッキンググループだと、以前に紹介したCharming Kitten(APT35)や
OilRig(APT34)が有名ですかね。
FireEyeもまとめているので、参考にしてください。
中華系、ロシア系、朝鮮系がどうしても印象的ですが、徐々にイランのハッカーも勢力を広げてきているのかもしれません。
AWS Elastic Beanstalkを使ってDjangoアプリをデプロイしてみた(後編)
前回の記事では、クラウドサービスについて、おさらいしつつElastic Beanstalkを使ってみようと思ったきっかけについて、書いてみました。
後編では実際の手順も含めて、ハンズオン形式でご紹介します。
目次
- はじめに
- 実行環境
- ローカルで仮想環境をセットアップ
- Djangoのインストールとプロジェクト作成
- Elastic Beanstalkデプロイ前の準備
- Elastic Beanstalkにサイトをデプロイ
- 環境クリーニング
- まとめ
はじめに
アプリケーション作成のフレームワークは正直何でもよかったのですが、私自身アプリケーション開発経験があったのが、DjangoとRuby on Railsくらいなのと、RubyよりもPythonの方が使い慣れているということもあって、Djangoを選びました。
今回のテーマが「AWSのサービスを使ってみた」なので、詳しくは触れませんが、 実際に作ったアプリケーションなんかも、今後機会があればご紹介しようかと思います。
DjangoのアプリケーションをAWS Elastic Beanstalkにデプロイする流れは、AWSがドキュメントを公開しており、今回の検証も以下をベースに実施しました。
実行環境
今回、Elastic Beanstalkにデプロイする実行環境は以下です。
互換性によっては動作しないことがあるので、AWSとの動作保証が取れているバージョンを確認したうえで、実行してください。
ちなみに筆者が元々利用していたDjangoも3.1だったのでやり直しました(笑)
FAQ: Installation | Django documentation | Django
ローカルで仮想環境をセットアップ
Windows10で仮想環境をセットアップします。
コマンドプロンプトを立ち上げて、必要なパッケージをインストールします。
pip install virtualenv pip install awsebcli --upgrade --user
pythonやpipのインストールは本記事では取り上げないので、各自インストールしておいてください。
ちなみに、AWSのEB CLIはパスが通っていないと思いますので、以下の手順でパスを通すのもお忘れなく。
- Windows キーを押し「環境変数を編集」を検索してクリック
- ユーザの環境変数のPathを選択し、編集
- %USERPROFILE%\AppData\roaming\Python\Python38\scriptsを追加
- cmd再起動
その後、コマンドプロンプトを起動し、以下の通り、仮想環境を有効にしてください。 ここでは、eb-virtという名前で仮想環境を作成しました。
C:\>cd C:\Users\自身のユーザフォルダ //ホームパスへ移動 C:\Users\自身のユーザフォルダ>mkdir Django_workspace //Django_workspaceというプロジェクト用フォルダを作成 C:\Users\自身のユーザフォルダ>cd Django_workspace //Django_workspaceへ移動 C:\Users\自身のユーザフォルダ\Django_workspace>virtualenv .\eb-virt //仮想環境eb-virtを作成 C:\Users\自身のユーザフォルダ\Django_workspace>.\eb-virt\Scripts\activate //仮想環境を有効化 (eb-virt) C:\Users\自身のユーザ名\Django_workspace>
Djangoのインストールとプロジェクト作成
Djangoをインストールします。
(eb-virt)~$ pip install django==2.1.1 //先述の通り、執筆時点でDjango 2.2 は Elastic Beanstalk Python 3.6 プラットフォームと互換性がないため、2.1.1をインストールします。 (eb-virt)~$ pip freeze Django==2.1.1 ... //djangoのインストールを確認
Djangoのプロジェクトを作成します。
(eb-virt)~\Django_workspace$ django-admin startproject trial_django
Django_workspaceのtrial_djangoプロジェクトに移動し、Djangoサイトをローカルで実行します。
(eb-virt)~\Django_workspace$ cd .\trial_django (eb-virt)~\Django_workspace\trial_django$ python manage.py runserver
ブラウザで、http://127.0.0.1:8000/ へアクセスして動作確認します。
こんな感じの画面が出れば動作OKです！
Elastic Beanstalkデプロイ前の準備
pip freezeの実行結果を、requirements.txtに出力し保存します。 Elastic Beanstalk は requirements.txt を使用して、アプリケーションを実行する EC2 インスタンスにどのパッケージをインストールするかを判断するようです。
(eb-virt)~\Django_workspace$ pip freeze > requirements.txt
.ebextensionsという隠しフォルダをプロジェクトのディレクトリ配下に作成します。
(eb-virt)~\Django_workspace\trial_django$ mkdir .ebextensions //.ebextensions という名前のディレクトリを作成します。
C:\Users\自身のユーザフォルダ\trial_django.ebextensions\django.config
といったディレクトリ構造にて、django.configを作成し、以下の設定を追加します。
django.configへの設定内容は以下です。
option_settings:
aws:elasticbeanstalk:container:python:
WSGIPath: trial_django/wsgi.py
一旦、ここで仮想環境を無効化します。
(eb-virt)~$ deactivate
Elastic Beanstalkにサイトをデプロイ
eb initコマンドで、EB CLI リポジトリを初期化し、django-tutorialという名前のアプリケーションをAWS Elastic Beanstalk上に作成します。
~\Django_workspace$eb init -p python-3.6 django-tutorial //先述の通り、AWSではpython3.6をサポートしています。
初回実行時には、AWSに認証情報を求められますので、以下の通り認証情報を入力します。
(aws-access-id):AWSのAccess key ID (aws-secret-key):AWSのSecret access key
認証情報がわからない場合には、アマゾン ウェブ サービス全般のリファレンスの「セキュリティ認証情報の取得方法」を参照してください。
作成したアプリケーションが稼働するEC2インスタンスにSSHでアクセスできるようにするため、再度、eb initを実行し、キーペアを設定します。 既存のキーペアを使う場合は1)を、新たに作成する場合は2)を選択します。
2)を選択した場合は、設定後に実行したフォルダ上の隠しフォルダ.sshに公開鍵が保存されるので、アクセス時に利用できるよう、覚えておいてください。
~\Django_workspace$ eb init Do you want to set up SSH for your instances? (y/n): y Select a keypair. 1) my-keypair 2) [ Create new KeyPair ]
この時点では、django環境は作成していないのでプロジェクトのみですが、AWSのコンソール上からも作成が確認できます。
続いて、Djangoの環境を作成します。
~\Django_workspace$eb create django-test
作成後、eb status を実行して新しい環境のドメイン名を確認します。
~\Django_workspace$eb status Environment details for: django-test Application name: django-tutorial ... CNAME: それぞれのドメイン名が出力されます。 ...
続いて、 C:\Users\ng7mi\Django_workspace\trial_django\settings.py を編集し、eb statusで確認したドメインをALLOWED_HOSTS = ['']の''の間に追記します。 この時、ついでにTIME_ZONEをAsia/Tokyoに変更しておくといいです。
そしていよいよ！ローカルのDjangoアプリをElastic Beanstalkにデプロイします。
~\Django_workspace$eb deploy
以下のコマンドを実行すると設定したアプリケーションがAWSにデプロイされアクセスできることが確認できます。
~\Django_workspace$eb open
無事、ロケットの画面にアクセスできました。
コンソール画面でもヘルスチェックがOKになっていることがわかりますね。
加えて、EC2の画面を選択し、「実行中のインスタンス」や「ボリューム」、「ロードバランサ」を確認すると、アプリケーションの実行に必要なインフラが構成されていることが確認できます。
環境クリーニング
そして最後に、環境のクリーニングを紹介しておきます。
前編のブログ記事で述べた通り、このままだとインフラの利用分だけ課金されてしまうため、アプリケーションを公開する予定などない場合は、一旦環境を削除することをオススメします。
ローカルの環境でアプリが完成し次第、また、デプロイすればいいと思うので。
コマンドはシンプルです。
~/Django_workspace$ eb terminate django-test
確認のため、削除対象の環境の入力が再度求められますので、django-testと入力し、削除を完了させてください。
ただこのコマンドだけでは、同時に作成されるS3のバケットが残ってしまいます。
ということで、S3の手動削除もご紹介しておきます。
- GUIにログインして、S3のマネジメントコンソールへ。
対象のバケットを空にする。
- この状態では、バケットポリシーにより、削除ができません。
対象バケットの管理画面に入り、アクセス権限のタブを選択。
バケットポリシー選択し、削除を実行。
再度S3のマネジメントコンソールへ移動し、対象のバケットを削除。
まとめ
こんな感じで、簡単にアプリケーションをAWS上にデプロイすることができました！
もちろん、EC2で一からインフラを構築して、アプリケーションをデプロイするのもアリだとは思うのですが、Elastic Beanstalkを利用すると、格段にラクだと感じました。
デプロイの容易性だけでなく、オートスケールなど運用における利便性も、推奨できます。
前編の記事でも紹介しましたが、以下のハンズオンを実施すると、Elastic Beanstalkの手軽さを感じられるのと、出来上がっていく環境への理解も深まると思うので、時間があればご受講をお勧めします。
ちなみに無料です。
AWS Hands-on for Beginners | AWS
こんな感じで、簡単な検証記事もちょこちょこ上げられたらなと思いますので、気まぐれ更新ではありますが、お付き合いください。
先日から公開している、ダイエット体験記のようなものも上げつつ、セキュリティ以外のコンテンツにも挑戦しようかなと思うので、良かったらご覧ください。
AWS Elastic Beanstalkを使ってDjangoアプリをデプロイしてみた(前編)
読者の皆様の中には、システムやアプリ開発でAWSを使って実装している方も多いかと思います。
私自身も、スクラップ&ビルドでいろいろなシステムやアプリを作っています。
いずれも、趣味の範囲でやっているものなので、どれも作り込みは甘く、文字通りスクラップしているようなことが多いです(笑)
そんな中、なぜAWSを活用するようになったか、そして、今回、AWS Elastic Beanstalkを使ってみてどう感じたか、簡単に書いてみようかと思います。
目次
そもそもAWSってなに？
当ブログをご覧いただいている皆様はご存じだと思いますが、改めて、AWSとは何かというところからおさらいしていきます。
まず、AWSはAmazon Web Servicesの略で、みなさんご存じ、Amazonが提供しているクラウドサービスです。
クラウドサービスとしての有名どころでは、同じ米国発のMicrosoft AzureやGCP(Google Cloud Platform)、中国のAlibaba Cloudがありますが、2019年度の世界シェアではAWSが首位です。
そもそもクラウドサービス？って思う方もいると思うので、その点も補足します。
早く本題に！と思う方もいるかもしれませんが、もう少しだけ、お付き合いください。
クラウドサービスとは
今思えば社会人になったばかりで、ITのIの字も知らず、ましてやクラウドも知らなかった頃が懐かしいです。
クラウドとは、企業が用意したリソース(サーバをはじめとした機器からソフトウェアまで)を利用者が契約した分だけ、インターネット経由で自由に利用できるサービスのことです。
AWSを例に挙げると、Amazonが用意するリソース(サーバをはじめとした機器からソフトウェアまで)が、まるでクラウド、つまり雲のように莫大で、利用者から誰でもアクセスできる様を表しているんじゃないかと、個人的には解釈しています。
そして、クラウドとひとえに言っても、種類があるので、軽くおさらいしてみます。
IaaS、PaaS、SaaSとは
クラウドサービスは大きく分けて、IaaS(Infrastructure as a Service)、PaaS(Platform as a Service)、SaaS(Software as a Service)に分けられます。
以下の図は、これらに加えオンプレミスを並べた時、ユーザが管理する範囲を青、サービスが管理してくれる範囲を示したものです。
図はRedHat参照
それぞれのサービスの特徴を簡単にまとめます。
- IaaS
PaaS
AWSを例に挙げると、以下のような分類です。 - IaaS - EC2 - PaaS - Elastic Beanstalk - SaaS - AmazonFSxなど
補足として、WordPressの構築などでよく利用されるレンタルサーバについても触れておきます。
レンタルサーバと言えば、とりあえずエックスサーバー！みたいに思う人も多いかと思いますが他にも
などたくさんのサービスがあります。
そしてこれらも、ユーザにインフラを提供するIaaSに分類できなくもなさそうですが、レンタルサーバはあくまで共有であり、リソース利用の柔軟性に難があると考えていただければと思います。
参考として、IDCフロンティアの説明記事を掲載しておきます。
勉強目的で使うAWSの利点
自身の端末のリソースを食いつぶさない
筆者も、少し前は、VirtualboxやVMwareWorkstationなどを使って、自身の端末上に仮想マシンを立てて、検証などを行っていました。
ただ、スペックもりもりのPCを使っているわけでもなかったので、ファンがワンワン言って、しまいには固まることも。。。
といった感じで、端末のリソース消費が一因となり、オンラインのリソースを活用できるAWSを最近は利用しています。
ただ、毎回EC2を立ち上げてOSを乗っけて、ということを繰り返してばかりで、多数リリースされているAWSサービスのことを理解するきっかけがありませんでした。
そこで今回、アプリケーションを別の方法で、AWSに乗っけられないかと思い、Elastic Beanstalkを利用してみました。
唯一の難点はお金がかかること
そんな、AWSですが、やはりお金がかかることは難点かなと思っています。
もちろん当たり前なことではあるのですが、パソコン買うのにお金かかってるのにまたかかるのかよーみたいになる気持ちもわかります(笑)
最近はサブスクリプション型のサービスも増えてきて、「購入しても自分のものにならない」文化が定着してきているように感じるので、徐々にこの辺りの抵抗もなくなってくるのかなと思います。
また、AWSには無料枠があります。
以下に掲載の条件の範囲以内であれば、無料で利用できるので、ぜひご活用いただくとよいかなと思います。
とはいえ、1年というのはあっという間に過ぎるもので、気づいたら課金額が増えていることが多いです。。
「EC2を停止し忘れる。」「EC2は停止したけど、RDSの課金が続いている」など、検証が終わったのにもかかわらず、課金が続いていくことはしばしば。
どれを使っているか使っていないかというのを考えるのは、非常に面倒だと感じていました。
こんな状況で利用を考えたのがElastic Beanstalkです。
Elastic Beanstalkを選んだ理由
今回、Elastic Beanstalkを使ってみたきっかけは、ずばり、「インフラを気にしないでよい」です。
先ほど述べた通り、EC2やRDSを設定して、必要に応じてスケールアップやスケールアウトをして、、という作業がまぁめんどくさい！
目的が、クラウドでのインフラの構築であれば、それでも良いのかもしれませんが、アプリケーションの開発や検証が今の自分のモチベーションなので、そこを気にしない世界を体験してみたかったというのが本音です。
実際に、筆者もAWSが提供する無償ハンズオントレーニングを実施して、インフラ周り含めた構築を体験した後で、AWS Elastic Beanstalkを使ってみましたが、手軽さが段違いでした。
AWS Hands-on for Beginners | AWS
以下、AWS Elastic Beanstalkからの引用です。
Elastic Beanstalk で追加料金は発生しません。アプリケーションの保存、実行に必要な AWS リソース（EC2 インスタンス、S3 バケットなど）に対してのみ料金が発生します。実際に使用した分に対してのみ料金が発生します。最低料金や前払いの義務はありません。
料金 - AWS Elastic Beanstalk | AWS
この説明にもある通り、デプロイ後、最小構成で、インフラが設定されて、その後Auto Scalingグループに基づいて、インスタンスの拡張を行ってくれます。
この点が、アプリケーションの開発や検証においては、ストレスを低減してくれるのではないかと思っている部分です。
まとめ
本当はElastic Beanstalkにアプリをデプロイするところまでを書こうとしたのですが、その前段でもりもりになってしまいました。。
次回の記事では、実際に実行してみた流れを踏まえてご紹介できればと思いますので、よろしくお願いします！
Alexaの脆弱性と悪用の方法について
セキュリティベンダーのCheckPointより、Alexaの脆弱性を悪用した攻撃手法の解説記事が公開されました。
脆弱性自体は、すでにAmazonによって修正済みだとのことですが、脆弱性がどういうものでどういった攻撃手法が使われたのかという点は、今後IoTデバイスと呼ばれる機器に起こりうる脅威を知る良いきっかけになると思うので、簡単にまとめてみます。
目次
脆弱性の概要とユーザへの影響
CheckPointの研究者によると、AmazonおよびAlexaが利用するサブドメインにCORS(Cross-Origin Resource Sharing)の設定不備があり、XSS(クロスサイトスクリプティング)の脆弱性が存在していました。
そして、XSSを悪用することで、最終的にCSRF(クロスサイトリクエストフォージェリ)トークンを取得し、被害者のAlexaにおいて任意のアクションを実行できるというものでした。
具体的には、次の章で記載します。
結果、これらの脆弱性により、攻撃者は以下のアクションを実行できます。
- ユーザのAlexaアカウントにスキル（アプリ）をサイレントインストールする
- ユーザのAlexaアカウントにインストールされているすべてのスキルのリストを取得する
- インストールされているスキルをサイレントに削除する
- Alexaで被害者の音声コマンドとその応答履歴を取得する
- 被害者の個人情報を入手する
攻撃者が、ユーザが細工されたリンクを一度クリックするだけで攻撃に成功します。
本脆弱性については、概要動画が公開されています。
攻撃の流れ
CORSポリシーの設定不備
Alexaのモバイルアプリには、通信の解析を妨げるための仕組みとして、SSL Pinningが実装されています。
そのため、CheckPointは、FridaのSSL universal unpinning scriptを利用してトラフィックを分析したようです。
トラフィック解析の結果、CORSポリシーの設定不備があるアプリから複数のリクエストが確認でき、Ajaxリクエストを別のAmazonサブドメインに送ることが可能になっていました。
このことから、攻撃者によって正規のサブドメインではないAmazonのサブドメインに対して、リクエストが送れる状態だったことがわかります。
Web通信の際は、各社のブラウザにてXSSを防ぐために異なるドメインへの通信を拒否するような仕組みが実装されているのですが、例外的に、その通信を許可するのがCORSという技術です。
図はクラスメソッドが運営する技術メディアサイトDevelopers.IO参照。
もちろん、その設定に不備がある場合、事実上のXSSを許可することになってしまい、脆弱性となるわけです。
レスポンスにCSRFトークンが含まれてしまう
トラフィック解析で確認された複数のリクエストのうち、いくつかのリクエストは応答として、「Alexaにインストールされたすべてのスキルの一覧」や「CSRFトークン」を応答として返すものもあるため、その後の、攻撃の幅を広げてしまっています。
Alexaのスキルというのは、Alexaのビルトイン機能で、いわゆるソフトウェアのプラグインみたいな位置づけです。
CSRFトークンを取得することで、攻撃者は遠隔から被害者の代わりにアクションを起こすことが可能になり、新しいスキルをインストールしたり、有効にしたりできてしまうわけです。
コードインジェクションの実行
今回の検証では、track.amazon.comへ送ったリクエストの応答として、paginationTokenとpageSizeが含まれていました。
pageSizeを変更すると、サーバー側からステータスコード500とJSONを応答と指定受け取れるのですが、応答のコンテンツタイプはapplication/json ではなくtext/htmlでした。
そのため、パラメータを加工することで、コード実行が以下のように可能になってしまっています。
これにより、被害者に成りすまして、skillstore.amazon.comへAjaxリクエストが送れてしまいます。
さらに、以下に示す、すべてのCookieをskill-store.amazon.comに送信させるリクエストを実行することで、レスポンスとして、csrfTokenが取得できます。
このcsrfTokenとインストールさせたいスキルのスキルIDを利用することで、被害者のAlexaにスキルを仕込むことができます。
同様にして、削除も可能です。
これらを組み合わせて、スキルをサイレントインストールで差し替えておくと、Alexaに声で命令した時に、攻撃者の用意したスキルを実行させることもできます。
例えば、「Alexa、エアコンつけて」って言ったら、「銀行の口座情報をLINEの特定アカウントに送る」みたいな。
スキルは、認証情報そのものは取得できなくても、認証情報を用いて取得できる情報(例えば、登録している情報や利用履歴など)は取得できてしまうので、注意が必要ですね。
実際の攻撃の例については、CheckPointの記事にも記載があるのでご参照ください。
まとめ
簡単な紹介ではありましたが、Alexaのスキルを遠隔から操作できてしまう脆弱性でした。
これからIoTデバイス向けのアプリケーションはたくさん作られていくかと思いますが、Webアプリケーション同様、しっかりとしたセキュリティ実装が必須になってくると思われます。
使うスキル自体は変わらないかもしれませんが、対象となる製品やサービスの幅が広がっていくことをそうていすると、セキュリティエンジニアはまだ需要がありそうですね。
具体的にいうと、アプリケーションのセキュリティ実装レビューができる人、ペネトレーションテストができる人、パケット解析ができる人なんかは引き続き重宝されそうですね。
コロナ太り解消！若手社会人が自粛期間を利用して無理なく6キロ落とした話～メンタル編～
シリーズものとして書いている「コロナ太り」に対抗するためのダイエット記事について、今回は最終回「メンタル編」です。
おさらいとして、私自身、5月2日から7月23日の約1か月半で体重を約6.3kg(62.7kg→56.4kg)減らすことに成功しました。
ダイエットの経緯や減量後に感じたメリットなどや食事法、運動のコツについては、これまでの記事を参考にしていただければと思います。
それでは、メンタル編、スタートです。
目次
ダイエットってきついよね
この記事を見ている人に限らず、ほとんどの人は「ダイエットはきついもの」と思っているかもしれません。
筆者も結果が出てブログにまとめることで、成功体験のように話していますが、ダイエットをするって考えたらキツイですし、たぶん続きません。
ではなぜ筆者がダイエットに成功したか、それは、「ダイエットを目的にしなかった」ということが要因だと思います。
具体的には、「食事や運動など生活スタイルを見直したらいつの間にか体重が落ちていた」、「新しい趣味に没頭していたらいつの間にか体重が落ちていた」という感じです。
つまり、人生を少し前向きに過ごすこと、少しだけハッピーに過ごしてみることが、成功につながるコツだと、筆者は考えています。
コツは人生を少しだけハッピーに過ごしてみること
みなさん、このCMに見覚えはないですか？
個人的にめちゃくちゃ大好きなCMで、曲の感じとかゆるキャラ感がツボなんですが、歌詞を聞いてみると、これまたいいことを言っているんです。
歌詞を以下に掲載します。（引用元はゼスプリの公式Youtubeチャンネル概要欄より）
体に良いことするのって大事
でも走るのは疲れる
筋トレは運動不足の人にはキツい
険しい山では思いがけず
キケンに遭うかも
足つぼマットはやっぱり痛い
ストイックにやっても続かない
ヘルシーは好きなことを楽しみながら
キウイ キウイ キウイを食べよう
甘くて 完熟で 栄養たっぷりで
アゲリシャス
キウイ キウイ キウイは最高
ヘルシーは好きなことを楽しみながら
ヘルシーは好きなことを楽しみながら
この「ヘルシーは好きなことを楽しみながら」ってのがいいですよね！
お気づきかと思いますが、この歌は決してダイエットのことを言っているわけではなく、体にいいことをする、そして、好きなことを楽しみながら という言葉を使っているんですよね。
だから、無理せず、楽しみながら、結果、健康的で理想のからだを手に入れる。
こんなイメージができるといいのかなと思います。
ちなみに、抜群のスタイルで有名なタレントで女優の菜々緒さんもダイエットについて、このように語っています。
脳が楽しくて幸せな状態を作りましょう。仕事でも趣味でも恋愛でも、何かに夢中になって時間を忘れるくらい何かに打ち込んでみては？ 食べる暇を楽しいことに変えてなくしましょう。でもバランスよくご飯は食べて栄養はとってね。笑
菜々緒さんが言うなら間違いないと思ってしまいますよね。
もちろん、並々ならぬ努力の上での発言だとは思いますが、楽しいことに変えるという発想は、非常に共感できるなと思いました。
楽しみ方のご提案
じゃあどうやって楽しめばいいのさ！
と考えている、読者の方々のために、いくつかヒントをお渡しします。
手間だけども少し充実度が上がる。
そんな感覚で、楽しみながらダイエットを成功させてもらえればと思います。
- SNSに上げてみる！特にインスタがおすすめ！
- 運動したよ！
- 走った距離や景色の写真を定期的に上げてみる
- ヘルシーな料理作ったよ！
- ヘルシーな料理を追及してフォロワーに共有してみる
- やせたって言われたよ！
- やせたって言ってくれた素敵な仲間との写真を思い出に残す
- なんだか顔が変わった気がする！
- 顔が変わったときの自分を写真におさめて、比較できるようにする
- こういう方法良かったよ！
- うまく言った方法などをフォロワーに共有してみる
- うまく言った方法などをフォロワーに共有してみる
- 運動したよ！
- 友達や恋人との共通の趣味に
- ランニングで近所を開拓してみる
- ランニングを通して、今まで気づかなかった街の魅力を再発見してみる
- 運動後のビールや檸檬堂
- 運動後のお酒を楽しみにして頑張ってみる
- むしろ、運動しないと飲んではいけないルールにする
- ランニングで近所を開拓してみる
- 熱中できる趣味を見つける
- 仕事へ還元したい人は
- プログラミング
- 読書
- 英会話
- ブログを書いてみる
- 心も成長させたい
- 映画
- アニメ
- 漫画
- 美術館巡り
- 写真
- 仕事へ還元したい人は
このような感じで、それぞれ一人ひとりにとって、一番頑張れる方法を見つけられるかと思います。
最近は、SNSの誹謗中傷なども問題になっていますが、日記代わりに残してみて、それが人のための情報になったら、これほどいいことはないのかなって思います。
投稿を通して、これまで気づかなかった仲間の趣味なんかにも気付けるのではないでしょうか。
今もなお、コロナ禍は続いていますが、SNSを通して、楽しみを共有できたりすると、理想なのかなって個人的には思います。
習い事のススメ
SNSの活用について、ご紹介しましたが、もちろんオフラインのつながりもとても良いです。
特に、個人的におすすめなのが、習い事を始めることです。
メリットは3つで
- お金を払うからかえって継続できる
- 仲間ができることで趣味の楽しみが倍増する
- ルーティーン化によりその時の自分の気持ちの変化に気付ける
私自身、社会人2年目からテニス、大学のころからストリートダンスを習っているのですが、とてもこれらの恩恵を感じています。
- テニスに行くために早起きをする
- ダンスに遅れないために定時で帰る
- テニスでおじさんたちに負け、ダンスで子どもたちに負け、年齢関係なしに悔しいからこそ謙虚になれる
- 仕事の肩書関係なく、何物でもない人として接することができる
- テニスでミスショットが多いとき、ダンスの振りが覚えられないとき、自身の集中力の低下や精神の疲労に気付ける
これ以外にもたくさんメリットがあります。
もはや、ダイエット関係ないですが、これだけ熱中できる環境があって、まだまだ自分が成長できると感じられることが、先ほどの菜々緒さんのコメントのように、食べる暇をなくすことにつなげられるのかなと思います。
ちなみに、コロナ太り解消に向けて動き始めてから、欠席したりすることが激減しました(笑)
環境を整えてみる
この章はご紹介程度ですが、ダイエットにお役立ちツール類をご紹介します。
自宅に用意する3種の神器
まず、amazonでポチッたものがこちら。
- 体重計
- 体脂肪率が極端に低く出てくるので、数値は正確でない気がしますが、変化が見られるのでいいかなと思ってます。
- 値段は5000円以下です。
- ヨガマット
- 最強です。コンパクトかつ、リーズナブル。
- 値段は1510円です。
- 入浴剤
- 正直種類は何でもいいです！
- お風呂に入る時間を設け、疲れをとる。これだけで充実します。
おすすめの書籍など
- 医師が教える食事術
- 食の知識をつける入り口におすすめ！
- もちろん、多角的な情報収集が大事ですが、基礎をこれで学んでみてください。
- Tarzan
- 高校くらいからの愛読雑誌です
- 定期的に買うほどではないですが、ダイエットや筋トレに目覚めるたびに買ってます。
それでも心が折れそうになったら
とはいえ、そこまで意志が強い人ばかりではないことも重々承知です。
心が折れそうになることもあると思います。
そんな時は、「休むこともダイエット」だと思っていいと思います。
運動編でもご紹介した通り、筋トレには超回復があります。
それと同じく、心にも超回復ってあるんじゃないかなと思っています。
火は一度消えてしまうと二度とつきません、どんなに弱火になってしまっても、火がついている限り、また火は強くなるものだと思います。
つらいときは、燃やそうと思うのではなく、消えない程度に休むこと。
ダイエットに限らず、そういう心があると長い人生も気楽になりますよね。
もっと言うと、ダイエットの本当の目的はやせておしまいじゃなく、「生活を変えて、継続すること」だと思っています。
無理せず、続けられる形で、取り組んでいただけるといいかなと思ってます。
まとめ
さて、全4回にわたってご紹介した、コロナ太り解消記事。
いかがだったでしょうか。
最後の方、個人の人生観丸出しになってしまいましたが、この記事を自分自身が見返したときに、その時の自分の支えになってくれないかな、なんて思ったりもしています。
そんなこの特集が、自分以外の読者の方にも、役立つと、なお嬉しいです。
元々、サイバーセキュリティの情報発信として始めたこのブログですが、広い意味で、ITと関わりのある多くの社会人にとってプラスになるコンテンツを提供できればなと思っています。
引き続きよろしくお願いいたします。
朝鮮系攻撃グループDarkHotelが悪用した可能性のあるMicrosoftの脆弱性CVE-2020-1380について
本日2つの情報が公開されました。
1つ目は2020年8月11日(現地時間)のPatch Tuesdayで公開された、悪用の事実を確認済みの脆弱性CVE-2020-1380およびCVE-2020-1464について。
こちらは、US-CERTからも注意喚起が出されています。
Patch Tuesdayというのは、当ブログでも何度か紹介していますが、Microsoft製品のセキュリティ更新プログラムが配信される毎月第2火曜日(現地時間)のことです。
2つ目は、2020年8月12日(現地時間)に公開された、Kasperskyの攻撃観測記事です。
この攻撃観測では、脆弱性CVE-2020-1380が朝鮮系の攻撃グループDarkHotelに悪用された可能性について言及しています。
今回は、これらについて、まとめます。
目次
2020年8月のMicrosoftセキュリティアップデートについて
2020年8月のMicrosoftセキュリティアップデートについては、JPCERT/CCやIPAからも注意喚起が発行されており、早急な更新プログラムの適用が推奨されています。
2020年8月マイクロソフトセキュリティ更新プログラムに関する注意喚起
Microsoft 製品の脆弱性対策について(2020年8月)：IPA 独立行政法人 情報処理推進機構
そして、今回注目すべきなのが、更新プログラムが公開された脆弱性のうちCVE-2020-1380およびCVE-2020-1464については、すでに悪用が確認されているという事実です。
これらの脆弱性について、先述の通り、US-CERTからは別で注意喚起がリリースされています。
簡単に両者の脆弱性をまとめると以下の通りです。
- CVE-2020-1380|スクリプト エンジンのメモリ破損の脆弱性
- Internet Explorer 11に影響を与えるリモートコード実行の脆弱性
- 当該脆弱性を悪用することで、攻撃者がIEの実行ユーザと同じ権限を取得できる
- 権限の高いユーザで利用中、当該脆弱性を悪用されると管理者権限で端末を操作される可能性がある
https://portal.msrc.microsoft.com/ja-jp/security-guidance/advisory/CVE-2020-1380
https://portal.msrc.microsoft.com/ja-jp/security-guidance/advisory/CVE-2020-1464
CVE-2020-1464については、報告者やその報告内容についてMicrosoftから明らかにされていませんが、CVE-2020-1380については、報告者が所属するKasperskyへの謝辞が記載されており、冒頭でご紹介した通り、攻撃に関する記事が公開されました。
今回確認されたDarkHotelの手法
Kasperskyが公開した記事では2020年の5月にKasperskyが対応した、韓国企業への攻撃において確認された2つの脆弱性の悪用について紹介されていました。
ひとつは6月に更新プログラムが公開されたCVE-2020-0986(Windows カーネルの特権の昇格の脆弱性)で、もうひとつは先ほど紹介したCVE-2020-1380です。
Kasperskyの調査では、CVE-2020-1380を悪用した攻撃を起点にシェルコードを実行し、ok.exeという名のファイルを一時ファイルに作成。
ok.exeには権限昇格の脆弱性CVE-2020-0986の悪用を含んでおり、実行後splwow64.exeのプロセスで、2種類の実行ファイルを実行することで、攻撃者の用意したC2サーバからzipファイルを取得し、upgrader.exeとして新たに一時フォルダに保存します。
その後、このzipを展開すると推測されますが、Kasperskyはこのファイルが取得される前に、攻撃を防いでおり、詳細の挙動は確認できていないとのことです。
Kasperskyはこれら脆弱性を悪用した攻撃をOperation PowerFallと名付けており、2019年11月に公開したOperation WizardOpiumとの類似性を認めています。
そして、Operation WizardOpiumの標的になったWebサイトのプロファイル情報がDarkHotelとの関連性を裏付けていたのと同様にして、今回のOperation PowerFallでも、背後にDarkHotelが存在するのではないかと予想しています。
DarkHotelとは
そもそもDarkhotelとはなんだろう、という疑問があると思うので、過去の攻撃などをもとに、まとめます。
攻撃の狙いとその手法
Kasperskyが紹介しているDarkHotelの説明記事によると、標的となったユーザは世界でも数千人にのぼり、感染の90%は、日本、台湾、中国、ロシア、韓国で、残り10%を欧米が占めているとのことです。
DarkHotelの目的は、マルウェアの挙動などから、組織や個人の機密情報取集だと考えられています。
活動の手法として、「スピアフィッシングメールに脆弱性を悪用したマルウェアを添付するパターン」と「ファイル共有サイトを悪用して無差別にマルウェアを拡散するパターン」があります。
特に、フィッシングメールに添付されるマルウェアが、AdobeおよびInternetExplorerのゼロディ脆弱性を悪用することが特徴として挙げられます。
ホテルの宿泊者を狙った攻撃
まさに、DarkHotelの名前の由来となった攻撃が、2014年11月に公開された記事で明らかになっています。
攻撃の手法は、高級ホテルのWi-fiに表示されたログイン画面に名前と部屋番号を入力し、ログインを行うとGoogleやAdobe、Windowsのソフトウェアのアップデートに見せかけたマルウェアのインストールに誘導されるというものでした。
そして、マルウェアのモジュールの中には、Firefox、Chrome、Internet Explorerに保存されたパスワードやGmail Notifier、Twitter、Facebook、Yahoo!、Googleのログイン情報を窃取するものも含まれていました。
当時の攻撃の流れを簡単にまとめた図が公開されています。
ちなみに、Youtubeにも動画が公開されています。
攻撃が高級ホテルのWi-fi経由だったことから、組織でも重役の人を標的にしていたと考えられている一方、その手法が無差別だったこともあり、一貫性に欠けるような様子も見受けられていました。
近年の攻撃
IPAのサイバーレスキュー隊（J-CRAT）が先日公開した、活動レポートによると、DarkHotelの関与が疑われるスピアフィッシングメールの国内事例が、2016年から直近の2019年まで断続的に観測されているとのことでした。
https://www.ipa.go.jp/files/000083013.pdf
また、同レポートでも言及されている通り、中国のセキュリティベンダーQihoo360も観測記事を公開しており、VPNサービスの脆弱性を突いた攻撃やIEとFirefoxの2つの脆弱性を利用した攻撃について触れています。
VPNの脆弱性を突いた攻撃については、元記事のリンクが消されてしまったようなので、日本語の解説記事を掲載します。
まとめ
DarkHotelについて、以前、ブログでもまとめたかなと思いきや初だったようです。
今回公開されたMicrosoftの更新プログラムにて確認できた、悪用確認済み脆弱性CVE-2020-1380には、果たしてDarkHotelの関与があるのでしょうか。。。
真偽はわかりませんが、とにもかくにも、少し感度を高めて、更新プログラムの適用を進めていただければと思います。
コロナウィルスだけでなく、こちらのウィルスもEmotetなどを中心に盛り上がっているのが大変残念です。
